When using the LLVM bootstrap to build LLVM and its libraries,
overriding just LLVM to disable tests during the first build doesn’t
seem to work. This stage name should remain stable, so check for it and
disable tests when building in it.
When compiler-rt targets Darwin, it is built with `-target`, which
causes clang to try to invoke `ld` without a target prefix (e.g., it
will try to exec `ld` instead of `x86_64-apple-darwin-ld` on a
cross-build to x86_64-darwin). Specifying `--ld-path` overrides that
behavior, allowing it to find the appropriate cross-linker.
The first build of compiler-rt in the LLVM bootstrap is build without
libc++ being available, which causes support for the `-g` flag to be
detected incorrectly on Darwin. Overriding the check by specifying that
it’s usable allows the first build of compiler-rt to succeed.
compiler-rt supports specifying the SDK path and version, so do that to
avoid needing to include `xcrun` as a native build input, which
simplifies the bootstrap.
Instead of using overrides in the stdenv bootstrap, Darwin will be
relying on the LLVM bootstrap to build compiler-rt. The only special
handling it needs is to use a stdenv with a bootstrap SDK instead of the
default one (to avoid infinite recursions).
While the Darwin stdenv bootstrap sets up its own clang wrappers and
doesn’t provide these wrappers in the final stdenv, it does use them
indirectly via the LLVM bootstrap to build LLVM and its libraries.
Note on using the system libunwind: It is possible to build and use the
LLVM libunwind on Darwin, but using the system by default one ensures
everything is using the same unwinder.
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
This reverts commit 019d091938.
My comments from the PR (which I only saw after it was merged):
> I'm not convinced this is a good idea — compiler authors turn things
> into errors for a reason, and as a distribution we have our part to
> play in getting problematic things fixed. It's fine to disable the
> errors for packages where it's not reasonably possible to get them
> fixed, but doing it globally means even packages that would be
> simple to fix properly don't get fixed.
> To expand a bit, the problem with this sort of thing is that it's
> very difficult later to tell when it can be removed. By setting this
> globally instead of setting it for individual packages that need it,
> we're effectively stuck with it forever, because it's impossible to
> tell if removing it is going to break any packages. If we mark
> packages individually, it's very easy to tell in future when those
> markings can be removed.
>
> This isn't a theoretical concern: something similar was done for
> pkgsMusl — some compatibility headers were added globally, instead
> of fixing individual affected packages, and now, even though we've
> discovered that the presence of those headers actually causes
> problems for other packages, it's impossible to know what the
> fallout would be of removing it. Let's not repeat this mistake.
So let's revert now, before it's too late.
See https://github.com/llvm/llvm-project/pull/100804 for further
context.
Tests for LLVM 12 to 16 pass fine without this change (the entire
section of the test doesn't exist there), our LLVM 19 already has the
patch applied.
cmake flags have a 'last flag wins' logic, so by appending to the end of
the flags it is possible to override any cmake flag.
It also ignores (and warns) if a flag is unused, so passing flags across
all packages should be safe if you want to target one package.
In combination with #320261, this PR allows consistently overriding all
packages within LLVM with additional cmake arguments. Consistency here
means for example 'if you override LLVM, then all dependencies on it are
also see the overridden LLVM in their input'. Consistency is hard to
achieve with the other obvious way of implementing this as a user: if
you use overrideAttrs then you have to write a big mess of override code
in order to override all dependents, and this can be very difficult in a
cross-compilation scenario using crossSystem and useLLVM, for example.
With this PR it is possible to write an overlay which overlays
`llvmPackages` with `llvmPackage.override { devExtraCmakeFlags = [ ... ]; }`,
and then the toolchain used with useLLVM in effect should respect
these flags.
This is useful in development for experimenting with the effect of
various flags, hence the chosen name `devCmakeFlags`.
This won't work out of the box without #341855 applied, which fixes
override passthrough.
See-Also: #320261, #341855
Signed-off-by: Peter Waller <p@pwaller.net>
Pull #320261 introduced the possibility to consistently override
dependencies within an llvm package set. I think #325175 accidentally
dropped this, so reinstate it.
Signed-off-by: Peter Waller <p@pwaller.net>
These have been failing to build on Hydra for over two months. It
looks like it might be a Python 3.12‐related thing, but the SWIG
4 patches wouldn’t apply cleanly and these old versions should
probably just be dropped anyway.
