Update config.nix to not need the lets

[Ericson2314]

This doesn't preserve hashes: The ghc used to build Setup.hs is now the normal ghcHEAD. If you want to make that yours too again, make the ghcHEAD override unconditional.

[angerman]

This doesn't build for me. Due to parsec only being shipped with recent GHCs. I'll see if I can amend it. As I mentioned in NixOS/nixpkgs#36200, I wonder if I can just inject a custom GHC, without having to override the ghcHEAD.

[Ericson2314]

Yeah sorry. I should have added I just instantiated it. It is plenty possible to not override ghcHEAD. I'll change this to do that.

[Ericson2314]

@angerman Ahhh. Yeah the issue with your old one is config gets applied to the build != host == target and build == host != target package set, but not the build == host == target package set.

But that's fine in this case as there's no reason to use ghcAngerman to build Setup.hs, as that will just make your debug cycle twice as long.

[Ericson2314]

@angerman Oh I see, the conventional ghcHEAD won't build Cabal, even if I add an explicit parsec dep. Wanna bump nixpkgs / bump ghcHEAD in nixpkgs so that we can dodge that? I can add the increase override support too, of course.

[angerman]

@Ericson2314 well, building HEAD with HEAD, is actually a common use case for cross compiler, if you want to get anywhere near abi stability.

For the "using" head situation, you mostly want

some ghc binary to bootstrap HEAD (stage2), which you use to build your Cross Compiler (stage1). As that point all your ghcs (cross and non-cross) are the same version, and have been built against the same packages, and use the identical code gen.

[Ericson2314]

That's fair; good to fix the override issue in any event. I'll aim do that later today.