Open EliteMasterEric opened 4 weeks ago
What OCaml version are you using (ocamlopt -v
)?
The OCaml native-code compiler, version 5.2.0
Standard library directory: /home/eric/.opam/default/lib/ocaml
If the version of OCaml needs to be locked to a specific version, then that should be part of the Github Actions workflow as well. You can see my failed workflow here:
https://github.com/EliteMasterEric/haxe/actions/runs/11301069165
We definitely want to support OCaml 5 in general, I think it's only going to require a few changes to make Haxe 4 compatible with it. In this case, we have to replace ExtLib.String.starts_with p.pfile
with fun s -> ExtLib.String.starts_with p.pfile s
.
I still haven't managed to get OCaml 5 running locally on my Windows machine, so it's difficult for me to work on this because I don't see the actual failures.
I haven't managed to get OCaml 5 running natively on Windows either, I ran my build via WSL just to see if I could get it working after I noticed the CI failure.
Whether or not Haxe wants to support OCaml 5, it currently does not. Github Actions should be version locked wherever relevant, particularly when mismatched versions can cause builds to completely fail with zero code alterations. I'd notably like Github Actions to work without code alterations as any of these would probably get merged only into the Haxe 5 branch (unless a 4.3.7 version is currently in the works).
The development branch works fine with OCaml 5 as far as I'm aware, so whatever change we make has to be made on the Haxe 4 branch anyway. I'd prefer to make a change that fixes something over a change that merely avoids the issue (and means we need two different OCaml versions for two different Haxe versions).
Try pinning extlib to 1.7.9
But it's set to "extlib" {>= "1.7.8"}
so I'd expect it to pick up 1.7.9 on a fresh install anyway... Still won't hurt to update that.
I checked 4.3.6 build logs vs what Eric is getting, and he's getting 1.8.0 (which is incompatible with 4.3_bugfix?) while 4.3.6 was built with 1.7.9
This error occurs when building on both Windows and Linux, and occurs for me both locally and when building via Github Actions, on commit ID 760c0dd, which is the tag of the 4.3.6 stable release.
Since the branch itself has not changed, I believe that this error may be a result of some dependency library not being locked properly.