Compiling projects with dependencies using GHC HEAD

Hi all, I have a project that I’d like to try to build with GHC HEAD, but it’s a large project with a lot of dependencies, and while there’s a lot of information on building GHC itself, I haven’t been able to find very many resources on what workflow people use to actually build projects in the wild using it. I found this wiki page, “Installing packages in your test compiler,” which has a little guidance, but the details are sparse: https://gitlab.haskell.org/ghc/ghc/wikis/debugging/installing-packages-inpla... However, I’ve been struggling to actually get my project to build using cabal-install paired with a stage 2 compiler. I realize some of this is just fundamental—various libraries need to be updated for new versions of GHC—but I’m willing to go to the effort to manually resolve those conflicts so long as I know the right way to go about doing it. One simple thing I did try (and failed at) is building an updated version of cabal-install itself using my updated GHC. From inside my checkout of the GHC repo, I tried the following: $ cd libraries/Cabal/cabal-install $ cabal --version cabal --version cabal-install version 2.4.1.0 compiled using version 2.4.1.0 of the Cabal library $ cabal --with-compiler=<path to ghc> --package-db=<path to package db> \ new-build cabal-install However, this failed to compile due to out-of-bounds versions of certain packages, so I tried again with --allow-newer: $ cabal --with-compiler=<path to ghc> --package-db=<path to package db> \ new-build cabal-install --allow-newer=base,ghc-prim,template-haskell This time, it managed to produce a build plan, but for reasons I don’t understand, both Cabal-3.1.0.0 and Cabal-2.4.1.0 are in the build plan, and the latter fails to compile against newer versions of base (due to the MonadFail changes). I tried to figure out what was causing Cabal-2.4.1.0 to end up in the build plan, but running new-build with the -v3 option didn’t seem to give me any more explanation. Apologies if this is really a request for support with cabal-install, and it doesn’t belong on this list, but I figured I’d start here, since I imagine the people on this list are best-equipped to answer questions involving using GHC HEAD. I’d appreciate any pointers or resources anyone has! Thanks, Alexis

Alexis King
Hi all,
I have a project that I’d like to try to build with GHC HEAD, but it’s a large project with a lot of dependencies, and while there’s a lot of information on building GHC itself, I haven’t been able to find very many resources on what workflow people use to actually build projects in the wild using it. I found this wiki page, “Installing packages in your test compiler,” which has a little guidance, but the details are sparse:
...
Apologies if this is really a request for support with cabal-install, and it doesn’t belong on this list, but I figured I’d start here, since I imagine the people on this list are best-equipped to answer questions involving using GHC HEAD. I’d appreciate any pointers or resources anyone has!
Hi Alexis, Your question is a very good one which, until quite recently, there was not a particularly good answer to. However, in the past months we have been working on infrastructure (in the form of head.hackage [0]) to make GHC more testable in pre-release form. I have a draft blog post explaining the currently state-of-play here [1,2]. Unfortunately between ICFP, release things, vacation, and bug fixing I've lacked the time to finish these off (the tutorial in particular). Also, note that this is still just infrastructure. While head.hackage does include a reasonable set of patches, it would be quite surprising if it has everything your project requires. Merge requests contributing new patches are highly encouraged. Cheers, - Ben [0] https://gitlab.haskell.org/ghc/head.hackage/merge_requests [1] https://gitlab.haskell.org/ghc/homepage/merge_requests/16 [2] https://gitlab.haskell.org/ghc/homepage/merge_requests/29

On Oct 1, 2019, at 18:19, Ben Gamari
wrote: Your question is a very good one which, until quite recently, there was not a particularly good answer to. However, in the past months we have been working on infrastructure (in the form of head.hackage [0]) to make GHC more testable in pre-release form.
I have a draft blog post explaining the currently state-of-play here [1,2]. Unfortunately between ICFP, release things, vacation, and bug fixing I've lacked the time to finish these off (the tutorial in particular).
Hi Ben, Many thanks for your response—this infrastructure looks incredibly helpful! I’ll give it a try. One question I do have just from giving it a look involves the cabal.constraints file available here: https://ghc.gitlab.haskell.org/head.hackage/cabal.constraints https://ghc.gitlab.haskell.org/head.hackage/cabal.constraints A number of packages appear to be listed twice, and some of them (but not all of them) are pinned to different versions. Is that intentional? Or is it just a part of still being a bit of a work in progress? In any case, this gets me quite a bit further, and though I’m not sure yet if my project will actually build, I can now at least construct a valid build plan. Thanks again! Alexis

Alexis King
On Oct 1, 2019, at 18:19, Ben Gamari
wrote: Your question is a very good one which, until quite recently, there was not a particularly good answer to. However, in the past months we have been working on infrastructure (in the form of head.hackage [0]) to make GHC more testable in pre-release form.
I have a draft blog post explaining the currently state-of-play here [1,2]. Unfortunately between ICFP, release things, vacation, and bug fixing I've lacked the time to finish these off (the tutorial in particular).
Hi Ben,
Many thanks for your response—this infrastructure looks incredibly helpful! I’ll give it a try. One question I do have just from giving it a look involves the cabal.constraints file available here:
https://ghc.gitlab.haskell.org/head.hackage/cabal.constraints https://ghc.gitlab.haskell.org/head.hackage/cabal.constraints
A number of packages appear to be listed twice, and some of them (but not all of them) are pinned to different versions. Is that intentional? Or is it just a part of still being a bit of a work in progress?
Indeed it's just a function of this being a bit work in progress; we only started allowing multiple patch versions relatively recently and it looks like the constraint file generation hasn't been updated to account for this yet. I'll try to fix that tonight.
In any case, this gets me quite a bit further, and though I’m not sure yet if my project will actually build, I can now at least construct a valid build plan. Thanks again!
Cheers, - Ben

On Oct 1, 2019, at 18:56, Ben Gamari
wrote: Indeed it's just a function of this being a bit work in progress; we only started allowing multiple patch versions relatively recently and it looks like the constraint file generation hasn't been updated to account for this yet. I'll try to fix that tonight.
Thanks for the clarification. I just wanted to follow up and say that this was indeed enough to get me off the ground, and I was eventually able to successfully compile my project with GHC HEAD after updating a few other dependencies for MonadFail compatibility. Thanks again for your efforts! Alexis
participants (2)
-
Alexis King
-
Ben Gamari