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>
Another year, another exhausting undermoderated thread full of people
arguing against being an inclusive community, tone policing and denying
that discriminatory behaviour even exists.
This clearly isn't getting any better and I'm embarrassed that I stayed
around for this long. I can't continue to lend my name to such a
project.
Fail to build with ninja 1.12 when NIX_BUILD_CORES is low (Hydra or Github Actions):
```
ld: warning: directory not found for option '-L/nix/store/g9rbp9m6vs1xj4jl6b6vjb6bm8kgr107-SDKs/MacOSX10.15.sdk/usr/lib/swift'
...
ld: warning: Could not find or use auto-linked library 'swiftCompatibility56'
Undefined symbols for architecture arm64:
"__swift_FORCE_LOAD_$_swiftCompatibility56", referenced from:
__swift_FORCE_LOAD_$_swiftCompatibility56_$_Optimizer in libswiftCompilerModules-bootstrapping1.a(Optimizer.o)
...
```
Can reproduce using `nix --option cores 2 build -f . swiftPackages.swift-unwrapped`.
Until we find out the exact cause, follow [swift upstream][1], pin ninja to version
1.11.1.
[1]: https://github.com/swiftlang/swift/pull/72989
Swift 5.8 doesn’t reliably build with Ninja 1.12, and apparently
neither do old versions of ROCm, due to a build scheduling change
breaking builds with undeclared dependencies. Upstream Swift have
pinned 1.11 for now.
Reintroducing it isn’t a good long‐term solution, but seems
like the easiest way to avoid shipping 24.11 with a broken Swift
on Darwin. The patch for 32‐bit systems has not been restored,
as Swift doesn’t support them anyway.
Peter Waller