Better native code support about haxelib HOT 9 OPEN

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

from haxelib.

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?

from haxelib.

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 😊

from haxelib.

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?

from haxelib.

@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. 😀

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

from haxelib.

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!

from haxelib.

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

from haxelib.

Any news on this @waneck ?

from haxelib.

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

from haxelib.