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"
```
- Tools from the glib.dev output need to be in PATH for cross
compilation to work. Not sure if there is a cleaner way than my string
trick to do it…
- The upstream configure script neglects to check for $AR properly, so
we need to pass it explicitly.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
since 2.8.5, shairport-sync uses the directory path sysconfdir to
determine where to place the configuration file shairport-sync.conf.
This led to shairport-sync complaining at startup:
> configuration file name "/nix/store/i8gb0hsb2zczdl8g1h73pbcb952585l9-shairport-sync-3.2.2/etc/shairport-sync.conf" can not be resolved.
Looking for a configuration file there doesn't make much sense, as we'd
have to include configuration in the shairport-sync derivation itself.
By setting sysconfdir to /etc/, shairport-sync will try to read its
configuration from /etc/shairport-sync.conf, which is a more sane
default.
Semi-automatic update. These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 3.1.7 with grep in /nix/store/8r3k0r8vf0wfpj14443pm1k0jddlnii2-shairport-sync-3.1.7
- found 3.1.7 in filename of file in /nix/store/8r3k0r8vf0wfpj14443pm1k0jddlnii2-shairport-sync-3.1.7
- Enable additional backends: pipe, stdout
- Support high-quality resampling with soxr
- Support configuration files, but don't install one
- Cut down on boilerplate code with fetchFromGitHub/autoreconfHook
