conda-forge / erlang-feedstock

A conda-smithy repository for erlang.
BSD 3-Clause "New" or "Revised" License
0 stars 11 forks source link

Aarch64 native build (without ppc64) #160

Closed danielhollas closed 1 month ago

danielhollas commented 1 month ago

Checklist

I noticed in the original PR #155 that the aarch64 build actually succeeded on Travis CI (without cross-compilation presumably). Let's try that!

conda-forge-webservices[bot] commented 1 month ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

danielhollas commented 1 month ago

@jakirkham a native build seems like a best way forward for the aarch64 build after all.

I'll still try to make the cross-compilation work for osx-arm64 / ppci64 but it is less of a priority for me.

  • [ ] Bumped the build number (if the version is unchanged)
    • [ ] Reset the build number to 0 (if the version changed)

Not sure if either of these are needed here?

jakirkham commented 1 month ago

Could you please help me understand the issue with PR ( https://github.com/conda-forge/erlang-feedstock/pull/159 )? It appears to be passing on ARM

danielhollas commented 1 month ago

In general, the issue is that the bootstrap build needs to be done with the toolchain of the build machine (x86), but the whole CONDA environment is setup for cross-compilation. So it is a bit difficult to separate the bootstrap build from the final cross-compilation build.

I've just pushed a new commit to #159 which should fix the ppc64 build. But I still think that a more robust solution for aarch64 is to build natively, most notably to ensure that the test suite passes. It might be possible to run the test suite with cross-compiled build as well, but I haven't figured it out yet.

jakirkham commented 1 month ago

Unfortunately the native builds currently use Travis CI. Recently Travis CI has become completely unusable to me. I cannot get the webpage to work at all. It's totally frozen as soon as I login. Have raised an issue with them, but it hasn't gone anywhere (it has been this way for almost a month).

In addition Travis CI has had issues where jobs won't start or get stuck. When I could use their page, I was able to restart them. Still not a great solution as it would be better not to have flaky builds at all. Though at least I had some ability to resolve the issue on my own. Now I am not able.

So while I understand cross-compilation can introduce its own extra complications, the Azure service it runs on has been consistently reliable. So feel I have a better chance at supporting that. With Travis, I cannot promise anything.

If you are willing to add yourself as a maintainer and you are able to restart Travis CI builds when they have issues, then we could work this out. If not, then I would prefer that we get the cross-compilation solution working on Azure.

Please let me know what you think

danielhollas commented 1 month ago

I've opened #161 for the discussion. I'll close this PR. If we decide to go with native build on Travis CI, we can do that as part of #159.