llvmPackages: unify version for all platforms but Darwin #343245
+3
−9
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, every platform uses LLVM 18 except for the following exceptions: * Darwin, on LLVM 16. * WASM, on LLVM 16. * Android, on LLVM 12. As discussed with RossComputerGuy and alyssais on Matrix, we plan to bump both Darwin and Linux to LLVM 19 after the 24.11 branch‐off, and try to keep them in sync after that, bumping to new stable LLVM releases immediately after releases branch off. This prepares for a 25.05 where `llvmPackages` is a simple platform‐independent alias by removing all the redundant branches and upgrading WASM and Android to LLVM 18. I checked with lilyinstarlight who did the previous LLVM bump for WASM and she confirmed that there should be no particular reason to keep it pinned to 16 so long as Firefox continues to compile, and I have confirmed that it does. Android was last bumped back when the other platforms were on LLVM 7, which is pretty good evidence that these platform‐specific conditionals create unnecessary divergence and bitrot quickly. Due to the “maximum‐of‐minimums” cross‐compilation logic, it was inevitably picking LLVM 16 or 18 anyway. `pkgsCross.aarch64-android.hello` fails the exact same way as it does on `master` on all the platforms I tested (compiler-rt failing to build on `aarch64-linux` and `x86_64-linux`, and the Linux headers package expecting `gcc(1)` on `aarch64-darwin`). I’m not entirely sure that the maximum‐of‐minimums logic is correct (should it be completely ignoring `buildPlatform` like this?), but since it will hopefully go away very soon I’ve decided not to spend more time thinking about it.
ofborg
bot
added
6.topic: darwin
emilazy
added
the
6.topic: llvm/clang
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
Currently, every platform uses LLVM 18 except for the following exceptions:
As discussed with @RossComputerGuy and @alyssais on Matrix, we plan to bump both Darwin and Linux to LLVM 19 after the 24.11 branch‐off, and try to keep them in sync after that, bumping to new stable LLVM releases immediately after releases branch off.
This prepares for a 25.05 where
llvmPackagesis a simple platform‐independent alias by removing all the redundant branches and upgrading WASM and Android to LLVM 18.I checked with @lilyinstarlight who did the previous LLVM bump for WASM and she confirmed that there should be no particular reason to keep it pinned to 16 so long as Firefox continues to compile, and I have confirmed that it does.
Android was last bumped back when the other platforms were on LLVM 7, which is pretty good evidence that these platform‐specific conditionals create unnecessary divergence and bitrot quickly. Due to the “maximum‐of‐minimums” cross‐compilation logic, it was inevitably picking LLVM 16 or 18 anyway.
pkgsCross.aarch64-android.hellofails the exact same way as it does onmasteron all the platforms I tested (compiler-rt failing to build onaarch64-linuxandx86_64-linux, and the Linux headers package expectinggcc(1)onaarch64-darwin).I’m not entirely sure that the maximum‐of‐minimums logic is correct (should it be completely ignoring
buildPlatformlike this?), but since it will hopefully go away very soon I’ve decided not to spend more time thinking about it.cc @rhelmot – do you expect bumping to LLVM 19 along with other platforms to be okay for FreeBSD?
Result of
nixpkgs-reviewrun on aarch64-linux 143 packages built:
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.