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? 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]
