On Wed, 21 Oct 2026 at 11:29, Brandon Allbery <[email protected]> wrote:
> There are already GHC-specific things in Cabal, along with Hugs-specific, > UHC-specific (although I think those might be getting removed), etc. > HaskellSuite got removed relatively recently! > Well yes, but that's for *invoking* GHC, not for *building* GHC. You wouldn't want special-case support in Cabal for building exactly one specific project, even if it is quite an important one. > On Wed, Oct 21, 2026 at 4:32 AM Simon Marlow via ghc-devs < > [email protected]> 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] >> > > > -- > brandon s allbery kf8nh > [email protected] >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
