As mentioned in #305146, keeping LLVM 12 is a source of pain because it
is the only version to be built from individual release tarball instead
of the LLVM monorepo. This commit makes LLVM 12 start from the monorepo
as well, simplifying all common LLVM expressions in the process.
With #347887, some quirks in the expressions for LLVM <14 were ironed
out, so building LLVM through from the monorepo is quite simple now.
- Most expressions only required minor changes, mostly removing the
special casing for `sourceRoot`.
- The patch lists from llvm/12/default.nix were ported to
common/default.nix. This only required a few extra conditionals which
could be reduced via a rebuild also involving other LLVM versions.
Outstanding tasks of little urgency have been noted in TODO comments.
I have verified that the patch lists stay the same for all packages
except LLVM where merely the order changes. An extra set of eyes
is appreciated, of course.
- clang: The expression was reworked to use the same symlink location
for clang-tools-extra for all versions including LLVM 12. This
required adjusting the ad hoc patching of the clangd cmake files
slightly.
- libunwind: We no longer need to make the libcxx sources available
manually. We can rely on the monorepo source instead.
- lld: We no longer need to make the libunwind sources available manually.
- llvm: We no longer need to make the polly sources available manually
- On Darwin, we need to bypass CMake's C++ compiler for libcxx and
libunwind now. It isn't a 100% clear why, probably because we've
started to use Darwin's bootstrapStdenv for libcxx in the common
expression compared to LLVM 12 on master [1].
The reordering of flags for wasm causes a rebuild for some packages
like firefox, but this should be tolerable on staging.
[1]: 665ebfb253/pkgs/development/compilers/llvm/12/default.nix (L392-L430)
(cherry picked from commit ee9eacf23e)
(cherry picked from commit c4e9f17ef9)
Pull #320261 introduced the possibility to consistently override
dependencies within an llvm package set. This is useful for development
and testing exotic configurations.
Go one step further and enable overriding targetLlvmLibraries.
This makes it possible to write an overlay such as:
```nix
overlays = [
(self: super: {
llvmPackages = super.llvmPackages.override (prev: {
targetLlvmLibraries = super.targetPackages.llvmPackages.libraries // {
compiler-rt = super.targetPackages.llvmPackages.libraries.compiler-rt.override {
...
}
};
});
})
];
```
... where the overridden compiler-rt will be used in a pkgsLLVM build.
As a straw man, I've done the minimally invasive thing to the code
structure: `targetLlvmLibraries` is not an explicitly named parameter
for llvmPackages; but it is available in `packageSetArgs` if passed.
This makes it slightly less discoverable, but this seems like a
reasonable tradeoff considered that modifying this would be a fairly
advanced/esoteric thing to need to do.
In some ways it would be better to have as an explicit parameter with a
default, but the obvious thing won't work because the default needs to
be a non-trivial expression. Potentially we could instead have it as a
defaulted parameter with the value of 'null', and if it's null, then
compute the current thing.
Signed-off-by: Peter Waller <p@pwaller.net>
