llvmPackages: Drop buildLlvmTools from llvm package derivations #359967
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
This an RFC in the form of a patch. I've noticed that if you try to build a (buildPlatform != hostPlatform) llvmPackages which aren't available via hydra, you incur a build of LLVM. (For example, pkgsStatic.llvmPackages_git.llvm does two builds of LLVM). LLVM has the capability of cross-building an llvm-tblgen internally. And tablegen is relatively cheap to rebuild, only requiring 8 CPU minutes or so to build. LLVM is much more expensive to build. So I propose to drop LLVM_TABLEGEN_EXE and related variables and let the LLVM build system do its thing. It does mean that a buildPlatform llvm-tblgen will get built (and discarded) repeatedly in different derivations (e.g. in .llvm and .clang), but at least it is less expensive than building LLVM and Clang twice. Note that I haven't interfered with the cross compiler wrapper logic, I think buildLlvmTools must remain there, only the llvm packages themselves. Signed-off-by: Peter Waller <[email protected]>
github-actions
bot
added
the
6.topic: llvm/clang
|
Another option could be to do a build of just tablegen in its own derivation, for a sort of best of both worlds with the tradeoff 🤔, but this would also mean a small amount of repeat building for the things which go into tablegen. |
nix-owners
bot
requested review from
alyssais,
dtzWill,
Ericson2314,
lovek323,
RossComputerGuy,
rrbutani and
sternenseemann
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.
This an RFC in the form of a patch.
I've noticed that if you try to build a (buildPlatform != hostPlatform)
llvmPackages which aren't available via hydra, you incur a build of
LLVM.
(For example, pkgsStatic.llvmPackages_git.llvm does two builds of LLVM).(OK, bad example, because it turns out llvmPackages_git is built by hydra! I didn't know that when I first wrote the message; However, if you change the hash of the compiler built, then it would result in a double build).
LLVM has the capability of cross-building an llvm-tblgen internally. And
tablegen is relatively cheap to rebuild, only requiring 8 CPU minutes or
so to build. LLVM is much more expensive to build.
So I propose to drop LLVM_TABLEGEN_EXE and related variables and let the
LLVM build system do its thing. It does mean that a buildPlatform
llvm-tblgen will get built (and discarded) repeatedly in different
derivations (e.g. in .llvm and .clang), but at least it is less
expensive than building LLVM and Clang twice.
Note that I haven't interfered with the cross compiler wrapper logic,
I think buildLlvmTools must remain there, only the llvm packages
themselves.
Signed-off-by: Peter Waller [email protected]
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.