Cannot build Haxe on Alpine Edge

[anjandev]

Hi,

I am trying to write a package for alpine linux using your docker recipe for alpine 3.20 :

https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69597

Although the package build works on alpine 3.20, it does not work on alpine edge. Moreover, it seems Celeste has some noted some issues you may have in the future:

https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69597#note_423099

I need to be able to package haxe in alpine so I can package a project I wrote using haxe.

Please let me know if you have a solution or if I can help test.

[andyli]

I am glad to see you're interested in packaging Haxe. Be aware it can take much more effort and time than one may have expected.

Building docker images and packaging for Linux distributions use different approaches. Here in docker-library-haxe we used opam to install OCaml compiler and libraries, but most Linux distributions require packages to use only dependencies from the distribution itself because the whole point of a "distribution" is to have consistency and compatibility across all the packages. That means, instead of using opam, you should specify OCaml and each OCaml libraries in APKBUILD's makedepends. That also means if any deps have not been packaged yet, you must package them all before you can package Haxe.

You may find the package source for other Linux distributions more useful (than the Dockerfile here):
Fedora: https://src.fedoraproject.org/rpms/haxe/blob/rawhide/f/haxe.spec
openSUSE: https://build.opensuse.org/projects/devel:languages:ocaml/packages/haxe/files/haxe.spec?expand=1
Debian (its package source format is quite different from others): https://github.com/HaxeFoundation/haxe-debian/tree/master/debian

For library compatibility issues, e.g. mbedtls 3 support, you will have to use patches. You can use the ones used in other distros, e.g. https://github.com/HaxeFoundation/haxe-debian/blob/master/debian/patches/mbedtls3.patch

[anjandev]

I added the patches and it mostly builds on alpine with mbedtls3 except for this error:

https://gitlab.alpinelinux.org/anjandev/aports/-/jobs/1578896#L1586

Do you know what Im missing? @andyli

[andyli]

The error showed that luv 0.5.12 failed to compile. You may try luv's latest version, i.e. 0.5.14 instead. Something like opam pin add luv 0.5.14 --no-action before opam install.

Note that the OPAM luv use its own vendored libuv. Again, I believe the proper way is to use alpine's libuv package instead, but it's all up to the alpine developers to decide whether its acceptable or not.

[anjandev]

https://gitlab.alpinelinux.org/anjandev/aports/-/jobs/1599186#L6556 @andyli new error!

[andyli]

HaxeFoundation/haxe#11787

[Cellesti]

As Andy has noted, packaging Haxe (and other OCaml packages in general) is not an easy task.

Based on the build log at https://gitlab.alpinelinux.org/anjandev/aports/-/jobs/1599186#L6223 it seems this is bringing back 3 packages (including camlp5) that were deleted from Alpine a while ago due to various issues.

While looking through git history, i also noticed that Andy was the previous maintainer of Haxe in Alpine, so maybe Andy can share more details surrounding the previous deletion of Haxe from Alpine.

I think the Alpine devs could use an assurance that Haxe will not be added just to be deleted again a few months down the line.

From the discussions on luv and extlib, it seems libraries installed through OPAM only have their versions pinned if there are issues. It may help if everything could be pinned like how Alpine packages Haskell projects (for example: cabal, hledger-stockquotes), which have all dependencies pinned to an exact version.

I understand that while this may not be usually done in OCaml circles, other languages have popularized the use of lockfiles, and Alpine has sort of grown to rely on this behavior whenever language-specific package managers like OPAM are used during a build, so having deterministic dependency versions could be another prerequisite for a package to be accepted.

[anjandev]

I have done the pinning. Now, I can reproduce https://bugs.gentoo.org/941760 and aantron/luv#159 on alpine:

https://gitlab.alpinelinux.org/anjandev/aports/-/jobs/1600571#L6083

[Cellesti]

According to https://gitlab.alpinelinux.org/anjandev/aports/-/jobs/1600571#L6010 you have only pinned luv and extlib, from what i see, there are around 20 packages still unpinned, so OPAM could potentially install differing versions of those depending on when it runs.

My intention in mentioning how Haskell projects are packaged is to point out that perhaps you have to pin all versions (other languages do that with a lockfile) in order to meet the criteria.

[anjandev]

I have done the pinning

I meant I have done the pinning for the packages other distros have pinned. Arch and gentoo only pin luv and extlib.

Yes, I will pin all the packages once I have gotten this package to build on alpine edge.

However, that log file's issue is not related to me not pinning all the dependencies. luv 0.5.14 doesnt work with haxe but I need luv 0.5.14 to build with the gcc 14 - the only gcc available on alpine edge. See: aantron/luv#159

As far as I can tell, the latest haxe release cannot build with gcc 14 which is the only gcc that will ship with the next release of alpine.

[anjandev]

Haxe has been merged into alpine edge 🚀🚀🚀🚀