Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make tooling lix compatible #686

Open
nulld opened this issue Dec 3, 2020 · 2 comments
Open

make tooling lix compatible #686

nulld opened this issue Dec 3, 2020 · 2 comments

Comments

@nulld
Copy link
Contributor

nulld commented Dec 3, 2020

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
Copy link
Member

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
Copy link
Contributor Author

nulld commented Dec 6, 2020

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants