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"
```
The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
stdenv.targetPlatform really shouldn't be used by software that
doesn't generate or manipulate binaries. I reviewed all uses of
targetPlatform outside of pkgs/development/compilers and pkgs/stdenv
and replaced those which weren't involved in something which fits
these criteria.
These versions don't build because their submodules use `git://` URLs,
which are no longer supported by GitHub.
I don't think there's a reasonable way to work around that since
`fetchgit` doesn't allow patching the source *before* fetching
submodules.
Currently, it is quite hard to override anything about dfhack (for
example, to add plugins at build time), because
1. it is not exposed anywhere, so you have to do something like
`dwarf-fortress.override (oldArgs: { dfhack = oldArgs.dfhack.override...; })`
2. the final `dfhack` derivation is a `buildEnv`, so `overrideAttrs`
doesn't work as expected.
This fixes 1 by adding `dfhack` to the wrapper's `passthru`, and 2 by
moving `twbt.lib` (which is the only reason for the dfhack `buildEnv`)
into the wrapper.
Also adds an `extraPackages` argument to the wrapper, and copies `*.init`
files from the env to the DF directory so that we can easily add a
`dfhack.init`.
With these changes, I was able to build dfhack with the dfplex plugin.
Since the setting DCMAKE_SKIP_BUILD_RPATH was disabled, we can now run
the checkPhase of cmake derivations without having to tweak the
LD_LIBRARY_PATH anymore.
