Open alpmestan opened 6 years ago
Well, at the moment ghc.nix
doesn't even try to support it (by supplying suitable definitions for the various relevant phases of building a derivation: configurePhase
, buildPhase
, etc). We've just all been focusing on making it good at giving us shells where we can productively work on GHC, not at making it an alternative to the haskell.compiler.ghcHEAD
derivation in nixpkgs, or to @mpickering's https://github.com/mpickering/ghc-artefact-nix, which both allow us to get a proper nix derivation for GHC HEAD builds.
Not sure how relevant it would be to give this a shot today, and how useful the code that we have for the shell would be to create the derivation. We'd get all the build inputs for free, but the entire build recipe would have to be written.
@mrkkrp Do you have a particular motivation for wanting to accomplish this in ghc.nix?
Using nix-build
for GHC development would not be very ergonomic as you would end up rebuilding the whole compiler every time you made a change. I say, close this as wontfix
.
We're working on setting up CI for our GHC fork at Tweag (the one with linear types). We have Buildkite agents with automatic nix cache and I'm thinking about a way to use nix cache to make the builds faster. Would something like building stage 1 and stage 2 as separate derivations help?
No, I don't think so because you have to rebuild if anything about stage1 changes.
See: https://www.haskell.org/ghc/blog/20190731-hadrian-cloud-builds.html
A proper description here would help. What is the principal difficulty with
nix-build
?