make tooling lix compatible about nme

[hughsando]

haxelib would run "run.n" - this is the main reason for using neko. The other one is dependencies. ie, the nme command line tool links against gm2d for svg icon rendering, which means you would need this library installed to run any nme code. It is not a big library, but I dislike imposing dependencies on users. There were also issues when trying to run haxelib interpreted rather than with neko - it would pick up stuff from nme class path (haxe.Timer maybe?) and would not run. I could possibly switch to cppia, and combined with lix may give a neko-free solution.
Either way, I'm sure we can get getHaxelibPath to work with lix instead of haxelib without too much trouble.

[nulld]

haxelib would run "run.n" - this is the main reason for using neko.

This is not only way. For now, it's possible to use not compiled haxe code via interpreter as alternative. It has full sys package access, so seem like it can replace neko (I'm a little bit bother of lack of neko support, seem that HF considered it as dead end) for case of nme tools.

There were also issues when trying to run haxelib interpreted rather than with neko - it would pick up stuff from nme class path (haxe.Timer maybe?) and would not run.

As I got it right, nme tool makes build.hxml from *.nmml and fiills it with -cp FooLib stuff. And haxe compiler considers the order of -cp and if for e.g. -cp nmePath will be last, haxe compiler will pick up haxe.Timer from nme, won't it?

gm2d for svg icon rendering

Not sure, that it will work in interpreter mode tools. Will think about this. Can we gather all things that requires to be inside native process, build it with hxcpp, and run from haxe interpreter?

I could possibly switch to cppia, and combined with lix may give a neko-free solution.

Sounds great!