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.
Ideally we don't want to use bintools.bintools and also not really
encode knowledge of what is wrapped and what not in our GHC derivation.
Unfortunately, not all tools are part of the wrapper derivation as well.
This should be gradually improved (e.g. in the case of the darwin tools
and strip).
Some GHC bindists have a normal `$out/lib` directory which contains
symlinks to all core libs. Because it is a normal lib directory, the
bintools setup hook will pick up on it and cause ld to pass the
appropriate -L and -rpath flags. We do not want this to happen,
especially in the case of the stage2 compiler. Not only will the final
ghc have an unnecessary reference (and thus increased closure size) to
the binary ghc, but the extra libraries in the rpath mess with the rts
and cause e.g. segfaults in GHCi.
Unfortunately, there is no way to prevent this. It is a fundamental flaw
in the cc and bintools wrappers that they do not actually distinguish
between the roles of dependencies (build, host, target). Instead
the mangleVar* function will translate the dependencies split up by
roles into platforms. This means that the wrappers can't distinguish
between depsBuildBuild and depsHostTarget (== buildInputs) when natively
compiling. As long as we are natively compiling the wrappers will put
the stage0 ghc (be it in depsBuildBuild, nativeBuildInputs etc.) into
the linker flags of the final ghc.
The solution is to sidestep the issue. We just had ghc in depsBuildBuild
to have it added to PATH. GHC itself will pass the appropriate linker
flags if necessary. To avoid the setup hooks picking up on the GHC
libraries we just don't put it into depsBuildBuild or any other
dependency list. Since the GHC build system accepts the GHC binary via
an absolute path, we don't even need to add the stage0 GHC to PATH.
