Better native code support

[back2dos]

To quote Caue on this one:

For now, haxelib has a ndll folder, which is in the search path when using Lib.load(). The way it's organized isn't very good, since it mixes up 'platform' with 'OS'. For example, there is a Linux folder, but an ARM linux platform would need a different binary. Also, it would be very nice to determine a folder structure for native builds, so it would be possible to do e.g. haxelib build-native somelib to build the native binaries for the current platform.

Lastly, now that we have e.g. support for native java libraries, maybe we could include a java .JAR when targetting Java?

[waneck]

One issue that we have with this is that the only way to query the system's platform is with Sys.systemName(). So we either return custom strings like LinuxARM, LinuxARMv10, etc, or we include a Sys.systemArchitecture(). But this would require adding this API to neko/hxcpp

[back2dos]

I really have very little Linux knowledge, but shouldn't fetching uname -a do the trick on linux systems? I guess we should just get a way to retrieve the "platform" that's exactly suited for haxelib's purposes and then see whether or how it should go back into std lib.

In all honesty, I practically never deal with native stuff, so there's little I can do to help here I'm afraid. Could you look into this? Or somebody else?

[TheHippo]

I'm not familiar with the hxcpp build system, but since we have our own build tool which should be cross platform, why not solved this like node.js - npm / ruby - gem do it:

In the node.js world, if you like to ship a library (or module as they call it) you include a binding.gyp (example from the mongodb subproject bson) which trigger gyp to build the binary on your platform. As long as build tools (C/C++ compiler) are installed and all sources included the binary could be build after downloading the library the first time.

So if you have hxcpp installed and there is a buildNative.hxml (or whatever) in the root of the library start the compiler :blush:

[waneck]

wow, I really like how .gyp is so simple :) . Anyway, we've already got the hxcpp's build system, which uses an xml. I think it would be a good way to have a standard location for it to be. Also, for now many haxelibs already come bundled with their built ndlls. So maybe we can trigger the native rebuild only if the ndll is missing for the platform, don't you think?

[TheHippo]

@waneck Yes it is indeed pretty simple and works quite well. But I assume hxcpp's build will do the same for us.

If binaries come bundles with the library the should be preferred, but without having any statistics on this, I strongly doubt that most library developers provide binaries for 6 (Win, Win64, Mac, Mac64, Linux, Linux64) or more platforms.

I agree with you on the topic what should happen if binaries come bundled, but to be realistic: If automatic build works no library author will ever boot multiple VMs to compile his library multiple times. :grinning:

Maybe add another command to haxelib: haxelib build libraryname and haxelib build libraryname --target targetname if some cross compiling is involved.

[waneck]

some libraries are not so easy to build (e.g. NME), so it might still be necessary. (although it would be nice to have haxelib build download all native dependencies as well. NME's got the sdl-static dependency it has to build against).

I like having haxelib build libraryname for native builds!

[back2dos]

I've assigned this to you @waneck, since I haven't the slightest clue what to do about it.

[back2dos]

Any news on this @waneck ?

[waneck]

No but it's now back into my mind. I'll think about a solution and propose here