Sure... just to be clear: our goal is definitely to *decouple* GHC and cabal, not make them more intertwined! It just so happens that lots of things that you need in order to build GHC with cabal... happen to be generic problems in our view:
* per-file (or even per-function) compilation flags... I'm afraid I can't find the GHC ticket right now * proper cross compilation support with a staged solver (https://github.com/haskell/cabal/pull/12356) * any interface at all to do something useful with the build artifacts that is NOT merging them to the filesystem (e.g. creating a bindist or use a custom merger) There may be things that will still require some glue code, but our goal is definitely to be able to do `cabal install ghc` and have it compile a stage1, then a stage2 ghc and install it nicely, without GHC- specific features in cabal. Yes, that may not be the workflow that GHC devs need, but it will anyhow reduce the need for glue code. Maybe we can simply delete most of hadrian once this is possible and just keep those parts that are truly GHC specific. You can reach out to us on the discord: https://discord.gg/NekCNkCeJ I also gave a presentation last ZuriHac: https://youtu.be/BtTaT90OvPE?si=2BGJb_f9Ck4TcT63 The code is here: * https://github.com/stable-haskell/cabal * https://github.com/stable-haskell/ghc Cheers, Julian On Wed, 2026-10-21 at 09:32 +0100, Simon Marlow via ghc-devs wrote: > On Wed, 21 Oct 2026 at 06:15, Julian Ospald via ghc-devs > <[email protected]> wrote: > > I mean, to no surprise, I support this (because I work with Moritz > > and > > Andrea on this). > > > > I believe having a buck2 backend for cabal is cool... and being > > able to > > build GHC end-to-end via cabal is cool too. > > > > That way we fix these problems more generically. There's certainly > > some > > smaller parts that we won't be able to do with stock cabal, which > > GHC > > needs (e.g. creating the bindist), but even for that... we have > > ideas. > > > > So I think we're maybe more aligned than we think we are: > > > > - stable-haskell wants to build GHC via cabal > > - Simon wants to build GHC via buck2 > > - we all want to be able to plug in different backends for cabal > > (as > > in: executing a build plan) > > > > What we're more concerned about is probably just that replacing the > > hadrian ad-hoc logic with some other ad-hoc logic (even if buck2) > > is > > gonna set us back in our efforts of removing most of that custom > > build > > system stuff from GHC. Even if a custom buck2 system is better than > > hadrian, it will still have all the downsides of a custom build > > system > > (hard to learn, bootstrap, maintain, ...). > > > > If it's opt-in via cabal backends, then that's another story > > entirely. > > > > Does that make sense? > > > > > Absolutely. I'm fully on board with making Cabal able to describe the > GHC build. (Although admittedly I'm a bit hazy on how you actually do > that without putting GHC-specific things into Cabal, maybe I should > look more closely at how Stable Haskell works). The ideal situation > is that you can use either plain Cabal or Cabal + some other backend > (Buck2!) to build GHC, and then packagers can be happy because they > don't have an extra dependency. > > I don't think you'd want to do GHC *development* using plain > Cabal, because it's not a good incremental build system - there's a > long list of problems both of the unsoundness variety and the > performance variety. End-to-end building for distros is fine, but for > development I think we want Cabal to be the front end to a good > incremental build system. We could invest in making Cabal a better > incremental build system, but that's probably not the best use of > resources. > > Cheers > Simon > > > > On Wed, 2026-10-21 at 07:18 +0900, Moritz Angermann via ghc-devs > > wrote: > > > > Perhaps Buck2 won't be the ultimate solution. Much of the work > > > > here could be reused by something else, because `cabal buck2` > > > > generates an intermediate "build spec" (basically a JSON blob > > > > of > > > > Cabal's build info) from which the Buck2 rules are generated, > > > > so it > > > > would be straightforward to retarget that for another build > > > > tool. > > > > What other options are there? > > > > > > Nix, jinja, make? Again, if we have everything modeled as a > > > generic > > > cabal project, and can use cabal to build it, or produce a buck2, > > > or > > > other backend output (wasn’t there even a shake backend for cabal > > > somewhere?), this will not only work for GHC, but for _any_ cabal > > > project. > > > > > > Also it will mean anyone familiar with cabal projects will be > > > able to > > > work on GHC fairly quickly. > > > > > > And last, the effort sunk into Hadrian could instead be sunk into > > > finally making cabal better. (Fixing bugs! Not making it a custom > > > GHC > > > builder—that would benefit everyone). > > > > > > Let’s reduce complexity together! > > > > > > Best, > > > Moritz > > > > > > PS: yes I know I have been heavily involved in the development of > > > Hadrian and have been calling for its sunsetting for a long time > > > now. > > > My vision for Hadrian has always been just as a stepping stone > > > towards a cabal built GHC. > > > > > > On Wed, Oct 21, 2026 at 1:17 AM Simon Marlow via ghc-devs > > > <[email protected]> wrote: > > > > On Tue, 20 Oct 2026 at 15:40, Simon Jakobi > > > > <[email protected]> > > > > wrote: > > > > > Simon, you might also tend to it a > > > > > bit, and bring it to level of usability that is above what we > > > > > have now > > > > > with Hadrian. Would that be a realistic expectation? > > > > > > > > > > > > > > > > > Yes that's the plan, if we decide to go this route. > > > > > > > > Cheers > > > > Simon > > > > > > > > > > > > > > Am Mo., 19. Okt. 2026 um 16:07 Uhr schrieb Simon Marlow via > > > > > ghc- > > > > > devs > > > > > <[email protected]>: > > > > > > > > > > > > As I mentioned to a few people recently, I wanted to > > > > > > explore > > > > > > replacing Hadrian with Buck2. I've got a prototype to the > > > > > > point > > > > > > where it can build the stage2 compiler and all the > > > > > > libraries on > > > > > > Linux: > > > > > > > > > > > > > buck2 run :stage2-ghc -- --interactive > > > > > > GHCi, version 10.1.20261017: https://www.haskell.org/ghc/ > > > > > > :? > > > > > > for help > > > > > > Using default language edition: GHC2024 > > > > > > ghci> 1+2 > > > > > > 3 > > > > > > ghci> > > > > > > > > > > > > This includes dynamic/static, all the RTS ways and > > > > > > profiling is > > > > > > allegedly working although I haven't tested it very much. > > > > > > > > > > > > It's a LOT smaller than Hadrian - hard to say exactly how > > > > > > much > > > > > > because some of the code is in the shared projects cabal- > > > > > > buck2 > > > > > > and haskell-buck2, but there's about 1400 lines of Buck2 > > > > > > stuff > > > > > > in the ghc repo and nothing in the library submodules. > > > > > > > > > > > > I've written up the design along with some notes on how to > > > > > > set > > > > > > it up and try it over here: > > > > > > https://github.com/simonmar/ghc/blob/buck2/README.buck2.md > > > > > > > > > > > > Keen to hear what people think about this. Are there key > > > > > > metrics that we should measure to understand whether it's > > > > > > better than Hadrian? What are the workflow aspects that > > > > > > people > > > > > > find slow currently? > > > > > > > > > > > > Cheers > > > > > > Simon > > > > > > _______________________________________________ > > > > > > ghc-devs mailing list -- [email protected] > > > > > > To unsubscribe send an email to [email protected] > > > > _______________________________________________ > > > > ghc-devs mailing list -- [email protected] > > > > To unsubscribe send an email to [email protected] > > > _______________________________________________ > > > ghc-devs mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > _______________________________________________ > > ghc-devs mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > ghc-devs mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
