Lix 16: New Major Release

1

Heyall,

For any lix users out there:

I’ve just published a new version of lix, which can handle multiple different versions of Neko at the same time, while not messing up older lix setups. If you update, you will thus have to run lix download to make sure neko becomes available (it is now stored in a different location compared to lix 15) - hence the major release. Other than that, there are no breaking changes.

The main point of this release is that different Haxe versions are built for different architectures and for them to work properly, the Neko binaries built for the same architecture need to be used along side those (primarily because haxe may call haxelib, which is a binary that dynamically loads neko and the dll/so must be compatible). Also, I’ve followed up with a bunch of patches already to sand of some edges I found while testing.

So far I was able to test on linux64, win64 and mac64 (intel). If someone could check with linux arm and apple silicon, that would be wonderful :wink:

Best,
Juraj

14 Likes
2

Hi Juraj, happy to see you around ! Thanks for your contributions to the ecosystem and community. Lix is a really useful tool. :heart:

1 Like
3

@back2dos I’m trying this on an Apple M4 machine. This is coupled with some other installing/uninstalling (downgrading npm) so I am hesitant to say this is a purely Lix problem yet. Anyway, here’s my situation.

which lix outputs /opt/homebrew/bin/lix

lix -v outputs 16.0.2

lix install haxelib:jsasync will install the library in ~/haxe/haxe_libraries properly

lix lime build html5 results in:

Error: Could not find haxelib “jsasync”, does it need to be installed?
Failed to invoke haxelib run-dir lime "/Users/alland/haxe/haxe_libraries/lime/8.3.0/haxelib" build html5 -debug because Error: Command failed: haxelib run-dir lime “/Users/alland/haxe/haxe_libraries/lime/8.3.0/haxelib” build html5 -debug

I tried removing that library dependency and the error continues with the other libraries.

Running haxelib config displays: /Users/alland/haxe/haxelib/ when it should be /Users/alland/haxe/haxe_libraries. Running haxelib setup changes the file at ~/.haxelib but the new directory is still not used. What else should I try?

5

Yeah, I think this is not particularly OS or CPU architecture specific. Lime has some pretty fancy library resolution logic (part of it is in lime, part of it in hxp), which apparently bypasses haxeshim and thus uses haxelib’s resolution rules. I’ll have to see what I can make of it.

That is “correct”. While haxeshim does hijack the path command to work differently in scoped environments, the idea is to leave haxelib otherwise untouched, so that people who use lix only for Haxe version management can do so and rely on haxelib to work normally. So haxelib config will point to the directory that the haxelib actually works with (it has a different structure than lix/haxeshim use, so the directories cannot overlap).

For unblocking, I would suggest to install the dependencies with haxelib too. Not exactly great, but I suspect that’s why it worked for you previously.

FWIW, you could also consider InnoGames’ lime-less OpenFL fork: GitHub - innogames/openfl: The "Open Flash Library" for fast 2D development … I’m not sure that’s even an option for you, but if so, you could expect faster and smaller builds.

In any case, I’ll have to see if there’s a way to coax lime into working with lix ^^

6

Thanks. The dumb thing is I had Lix working with lime before and it used the proper paths. I shall endure…will report back when I figure it out.

7

Are you really sure though? If you went from non-lix to lix on your previous machine, chances are you simply had the required dependencies installed via haxelib too and that’s why it simply worked.

8

Yeah, I’ve been using the same machine since November and Lix was working. This error started when I was trying to add some “jsasync” library functions and then the Acorn.js bundler that haxe-modular uses started complaining about the output. After a few tries, GPT5 convinced me I had to downgrade Node from 22 to v.20. I ended up removing the default installation of Node. I don’t remember what problem that caused but I also upgraded Lix around that time. I just now installed the “official” Node package and this haxelib error is now replaced with lime complaining about my arm64 architecture. Progress! :slight_smile:

9

I am sort of back on track after reinstalling haxe and haxelib. Now I have an issue which is maybe Lix 16?

I was generating externs before and having Lix point to them locally. For example, my “three.hxml” file looks like:

-lib three
-cp ./externs/three/0,182,0/
-D three=0.182.0

Now on compiling it complains Could not find haxelib “three”, does it need to be installed? My externs are still there.

10

Sorry for all this spam. I’ve narrowed this down to haxeshim not being obeyed.

With my latest installations, lix has set up haxe to point to haxeshim.
When calling haxe from outside the project scope, the haxe version is set to 4.2.5.
Inside the project scope with Lix it is set to 4.3.7. So it seems that for some reason calling lime within the project scope is not using the correct version of Haxe. How do I force it to use 4.3.7 when calling Lime? And why is 4.2.5 the default?

11

Yeah. It’s tricky. The error message you’re getting comes from within hxp: hxp/src/hxp/Haxelib.hx at b90dee15b5c00e2bd10b86fdfee53f2c1b551e02 · openfl/hxp · GitHub

I’m not even sure how to fully build that correctly, because some part of the code is just missing: Where is InterpHelper? · Issue #12 · openfl/hxp · GitHub

It does seem to work with the prebuilt run.n so I tried neko run.n with a sample project, but there I can see that it resolves through haxeshim just fine. I tried to check out lime, but that adds a fair amount of indirection, that makes my head spin ^^

The most likely thing that is happening is that lime either:

  1. makes changes to PATH
  2. runs something in a working directory outside your scope, and thus makes haxeshim look things up globally (meaning you get the global haxe version and global library resolution which attempts haxelib based resolution if it fails through haxe_libraries)

You could try running the same with -verbose to see if that produces any information that might help track this down.

2 Likes
12

Well although the version of Haxe is not ideal, I eventually solved the problem made progress with 2 steps.

  1. Run Lime via Rosetta using the command arch -x86_64 zsh before building, which activates it for the current terminal. This resolves the complaints about the arm64 architecture. I reinstalled lime and ran haxelib run lime setup to resolve this.
  2. Use haxelib dev commands to resolve problem with not finding externs. This makes it “find” the library so it attempts to compile, but there are still problems.

One thing I neglected to mention is that I recently updated MacOS to Tahoe, which may have caused additional issues when I started reinstalling everything. To be certain, I allowed “full disk access” to haxe and haxelib binaries but I’m not sure if that helped. Thanks for your comments Juraj!