All targets

[lublak]

This list is only for documenting which interfaces exist.
(what can help is to autogenerate swig files? http://www.swig.org/)

Target	Interface	Implemented	Planned
Javascript	Emscript	false	false
NodeJs	N-API	false	true
HashLink	hdll	true	false
Eval	cmxs/cmo	false	true
JVM	JNI	false	false
PHP7	Extension	false	false
C++	CFFI or extern	true	false
Lua	C API	true	false
C#	P/Invoke	false	false
Python	ctypes	false	false
Java	JNI	false	false
Flash	NO!	false	false
Neko	ndll	false	false

[Aurel300]

Thanks for the links! I'm working on a restructuring of ammer. Here is the platform support I am aiming for:

Platform	Prototype?	Mechanism	Note
C++	yes	static link
C++		dynamic link	not useful?
C#	yes	P/Invoke
Eval		compiler plugins	issues with dune builds
Flash		AIR native extensions	(why bother?)
Hashlink	yes	hdll
Hashlink/C		static link	how to inline code into HL/C output?
Hashlink/C	yes	dynamic link
Javascript		Deno FFI
Javascript		Emscripten
Javascript	yes	N-API
Java	yes	JNI
JVM	yes	JNI
Lua	yes	C API
Neko	yes	ndll
PHP7		extensions	not useful? not enabled on shared PHP servers...
Python	yes	C API

"Prototype" means I have a build that for now just sends ints back and forth. "Dynamic link" vs "static link" refers to whether the glue code itself is part of the compiled binary. For C++ the code is generated directly so it does not make much sense to generate code that dynamically links to glue code (that will then dynamically link to a native library). Likewise for HL/C although I'm not yet sure how I can accomplish this.

Regarding SWIG: I guess ammer could be a "target language" for SWIG. That is, it could hopefully generate the ammer library definitions that would then allow Haxe to connect to the library, without anybody having to figure out the Haxe-library mapping manually.

[Aurel300]

The underlying framework ammer-core is now public. I will soon be replacing this repo with a complete rewrite based on ammer-core.