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