What to use? HxFFI or haxe.macro.Compiler for loading libraries dynamically

I have found two methods in which to load a library dynamically in a compiled native application using Haxe. The first is to use HxFFI, which is a library - which seems to be only on the legacy haxelib website, which makes things a little annoying - and looks very promising.

The other is to use the Compiler class found in the macros of Haxe to load libraries dynamically, which I’m guessing (emphasis on ‘guessing’) to use the static addNativeLib function there.

Now, as far as I am concerned, macros is just an all-rounder better and more catered for masters at Reflection-based programming, which I have some good knowledge of in C#, but barely any in Haxe.

My ultimate question is, which would be best used and are there any good examples on how to load (dynamically) an assembled file and call the main entry point? There is an example for hxffi but that library is now two years old and I am unsure it will be functional with Haxe 3.1.3; but I suppose there is no harm in trying.

What kind of library? A haxe one, a c/c++ one, other?

Also what do you mean by “main entry point”? A program has one, but libraries do not.

If it’s a c/c++ library these links might interest you:

You might also be interested in lime create extension MySampleExtension and checking out the source, you can lime rebuild MySampleExtension <target> to compile the C++ library included, and it gives a brief introduction to what Haxe CFFI bindings between Haxe and C++ look like

I saw a CFFI discussion on the Haxe google groups forum, which I did a search for before posting here. Good to have that clarification, though. https://groups.google.com/forum/#!searchin/haxelang/load$20libraries$20dynamically/haxelang/6lQNDwmLnSM/A98XE4gNZxgJ

In that discussion, they discussed a library called HxFFI, which is designed to, and I quote:

“…achieve interoperability with native libraries inside Neko/hxcpp . You can load a dll, get symbols and call functions, all dynamically.”

So, HxFFI is very interesting and maybe something I look into. Otherwise it’s just play around with what Haxe has to offer.

In case you were wondering, this is the kind of method I will be using to “live preview” video game development as you code, by having a host application that loads the library every second or so, calling a “main” function and loading all the necessary content on-the-fly, similar to how Casey does it in his Handmade Hero video series on YouTube.

As far as I am concerned, given what Casey states in his video series, loading a library dynamically is faster than using a scripting language… but I suppose that is arguable depending on language, environment, hardware, etc.

It would be a Haxe library, as described above, compiled using OpenFL to target cpp but instead of compiling an exe, instead compile a dll… Although I am not 100% sure OpenFL can do that, it may be the case of using haxe directly to do that

That’s interesting. We have live reloading for assets, but not for coding. This could be done, for sure, using JS or Neko, but in C++, there’s something in HXCPP now called “CPPIA” that’s designed to be a dynamic compile target (which could be reloaded at runtime), otherwise, I would like to see the Lime module system improve over time, so that you could have a host Lime application which loads a submodule, which could then be reloaded – effectively helping make this sort of live reload system official

My initial idea was to use a Node.js application and have it listen on port 3000, and whenever code was saved in the editor, it would automatically compile and the Node.js would reload the js files when the application receives a message to reload it.

Hmm… there is certainly a lot of options on how to do this live preview system. Since HTML5 and JS are already dynamic, and since your main focus is in fact to make HTML5 the first class citizen, I suppose it’s only natural to use Node.js?

Node Webkit is another option (or other WebView systems) to reload a pure JS version, or Node.js can use an NDLL for native code access and native windowing, if you have the NDLL module for Node working

Neko is also dynamically loaded, I had a NekoVM embed working in Lime at one point