stdenv.cross is a silly attribute that needs to go leaving the well-defined hostPlatform and targetPlatform. This PR doesn't remove it, but changes its definition: before it tracked the target platform which is sometimes more useful for compilers, and now it tracks the host platform which is more useful for everything else. Most usages are libraries, falling in the "everything else" category, so changing the definition makes sense to appease the majority. The few compiler (gcc in particular) uses that exist I remove to use targetPlatform --- preserving correctness and becoming more explicit in the process.
I would also update the documentation aside mentioning stdenv.cross as deprecated, but the definition given actually erroneously assumes this PR is already merged!
The previous commit redefines `stdenv.cross` for the sake of normal
libaries, the most common use-case of that attribute. Some compilers
however relied on the old definition so we have them use
`targetPlatform` instead. This special casing is fine because we
eventually want to remove `stdenv.cross` and use either `hostPlatform`
or `targetPlatform` instead.
In practice, this is a strictly stronger condition than target != build
as we never have build = target != host. Really, the attribute should
be removed altogether, but for now we make it work for plain libraries,
which do not care about the target platform. In the few cases where the
compilers use this and actually care about the target platform, I'll
manually change them to use `targetPlatform` instead.
- `ccWrapperFun` can be used in a few more places instead of
duplicating its definition.
- `ccWrapper` parameter on `wrapCC` is always substituted with
`ccWrapperFun` so just get rid of that parameter.
Each bootstrapping stage ought to just depend on the previous stage, but
poorly-written compilers break this elegence. This provides an easy-enough
way to depend on the next stage: targetPackages. PLEASE DO NOT USE IT
UNLESS YOU MUST!
I'm hoping someday in a pleasant future I can revert this commit :)
- `pkgs` is self-similar, and thus already spliced
- `buildPackages` is an ingredient of splicing and should be kept as is
- The platforms are not packages or package sets and couldn't be spliced
There's probably other things that shouldn't be spliced too. The best long-
term solution is simply to stop splicing altogether.
3.14 is no longer supported upstream by kernel.org and thus no longer
receives security patches. The git commit mentioned in this .nix isn't
even available in the linked repository --
https://chromium.googlesource.com/chromiumos/third_party/kernel -- so I
think this .nix might be dead anyway. Finally, it specifies 3.14.0,
which is so ridiculously old (the latest was 3.14.79) that nobody
develops for it.
Fixes: #25145
Supports: #25127
