search

haxenme / nme

A cross-platform native backend for Haxe projects
MIT License
479 stars 122 forks source link

make tooling lix compatible #686

Open nulld opened 3 years ago

nulld commented 3 years ago

Tried to use nme with lix and stucked.

Have spend some time to invistigate what's going on and found that some methods in tools/nme/src/helpers/PathHelper.hx doesn't works correctly in lix/haxeshim environment. getHaxelib getHaxelibPath for e.g.

Btw, did you considered porting tools from neko (which AFAIK going to be deprecated) to the new haxe interpretator? For now, all haxe library can have something like Run.hx which can do almost the same as run.n.

I could try to do it, if it doesn't diverges with your plans and views on how it would be.

@hughsando @thomasuster any thoughts?

hughsando commented 3 years ago

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 commented 3 years ago

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!