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]
