How did you test these changes?

Do ghcWithPackages and ghcWithHoogle still work properly?

I've only tested this with a mingw cross compiler. That is, I built the full ghc on the host:macOS, and a cross compiler:macOS -> mingw.

GHC needs one integer library be it integer-simple or integer-gmp.
When providing the GMP library, it needs to be the target one (as @Ericson2314 pointed out, targetPackages is essentially id when build == host == target).

GHC also has an--in-tree-gmp option, which is usually the fallback if no GMP library is found.

Do ghcWithPackages and ghcWithHoogle still work properly?

Also, could you please verify that those builds that are supposed to use the gmp-based integer library actually do so? The patch causes re-builds on all platforms, not just the interger-simple ones, so I reckon it might be a good idea to make sure there's no regression.

@peti Err the point of this is the GMP ones, not the integer simple ones. GMP was just being inferred by default before, and that inferred (on the GHC side) happened to be unreliable (in the cross case). This forces the build system to use GMP when we want it to. By contrast, I'm not sure why anything has changed for the integer-simple builds, unless those happen to depend on the GMP ones for some reason and thus are downstream rebuilds.

Err the point of this is the GMP ones, not the integer simple ones.

Yes, I understand what the change intends to do. I guess I was simply suggesting that it might be a good idea that that actually does what it's supposed to do and nothing else.

Anyhow, I'll trust your judgement. Proceed as you think would be best.

@matthewbauer Please use staging in the future.

Ok - will do that next time. Is that recommended for GHC though? Basically any change will be 500+ (no stdenv changes).

I think it's best to use https://discourse.nixos.org/t/the-haskell-infrastructure-needs-new-maintainers/545/11

Ok sounds good. Sorry for any inconvenience.