The problem is closely related to #10874. We've developed a habit to test stdenv.cross to find if we're cross-compiling or not. However, that does not work for native build inputs, i.e. they see the same stdenv arguments as the cross derivations.
What's worse, I don't think this is easily fixable. We call stdenv.mkDerivation with some arguments, and inside this call we call the original and modified mkDerivation to produce nativeDrv and crossDrv. Those arguments have no possibility to differentiate among the two cases during evaluation time. We can still use crossAttrs, but that's rather inconvenient if we only want to slightly tweak a substring of a phase or drop a build input.
(Attributes like stdenv.isLinux also evaluate the same always, but the problem there is reversed, as discussed in #10874: it shows properties of the build system even though users typically mean the host system.)
The problem is closely related to #10874. We've developed a habit to test
stdenv.crossto find if we're cross-compiling or not. However, that does not work for native build inputs, i.e. they see the samestdenvarguments as the cross derivations.What's worse, I don't think this is easily fixable. We call
stdenv.mkDerivationwith some arguments, and inside this call we call the original and modifiedmkDerivationto producenativeDrvandcrossDrv. Those arguments have no possibility to differentiate among the two cases during evaluation time. We can still usecrossAttrs, but that's rather inconvenient if we only want to slightly tweak a substring of a phase or drop a build input.(Attributes like
stdenv.isLinuxalso evaluate the same always, but the problem there is reversed, as discussed in #10874: it shows properties of the build system even though users typically mean the host system.)TODO by @Ericson2314
stdenv.crossis gonestdenv.is*with evaluation-time warningcrossAttrs#33302 RemovecrossAttrs(see cross stdenv adapter inpkgs/stdenv/adapters.nix)