1. Building and testing happen together. When tests failure spuriously, we also have to rebuild GHC in addition to re-running the tests. That's pure waste. https://gitlab.haskell.org/ghc/ghc/-/issues/13897https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F13897&data=04%7C01%7Csimonpj%40microsoft.com%7C3d503922473f4cd0543f08d8d48522b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637493018301253098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FG2fyYCXbacp69Q8Il6GE0aX%2B7ZLNkH1u84NA%2FVMjQc%3D&reserved=0 tracks this more or less.
I don't get this. We have to build GHC before we can test it, don't we?
2 . We don't cache between jobs.
This is, I think, the big one. We endlessly build the exact same binaries.
There is a problem, though. If we make *any* change in GHC, even a trivial refactoring, its binary will change slightly. So now any caching build system will assume that anything built by that GHC must be rebuilt - we can't use the cached version. That includes all the libraries and the stage2 compiler. So caching can save all the preliminaries (building the initial Cabal, and large chunk of stage1, since they are built with the same bootstrap compiler) but after that we are dead.
I don't know any robust way out of this. That small change in the source code of GHC might be trivial refactoring, or it might introduce a critical mis-compilation which we really want to see in its build products.
However, for smoke-testing MRs, on every architecture, we could perhaps cut corners. (Leaving Marge to do full diligence.) For example, we could declare that if we have the result of compiling library module X.hs with the stage1 GHC in the last full commit in master, then we can re-use that build product rather than compiling X.hs with the MR's slightly modified stage1 GHC. That *might* be wrong; but it's usually right.
Anyway, there are big wins to be had here.
Simon
From: ghc-devs