Yeh, on reflection I think what they'd _really_ like is something that fits their standard Haskell package workflow, which implies Setup.hs. The stable-haskell cabal-based install hopefully leads in that direction.
On Mon, Oct 19, 2026 at 8:29 PM Arnaud Spiwack <[email protected]> wrote: > > > On Tue, 20 Oct 2026, at 08:23, Brandon Allbery via ghc-devs wrote: > > FWIW what I've heard from packagers over the years is that Hadrian is an > unwanted pain point for them. > > On this front, I think Buck2 may very well make the matter worse, not > better. Hermetic build systems really like to control the world and don't > play very well with package manager builders. Though maybe it's a problem > we have more experience with, surely there's some big Google project build > with Bazel which is routinely packaged? > > Regardless I would be quite favourable to using a more well-used tool for > GHC's build system, as we get to benefit from the work of all our friends > who also use Buck2 (or any alternative) for free. The improvement in hot > build times are very welcome too. The perspective of better build caches > while alternating through branches (or even different checked-out trees, > via remote caching) is appealing. But mostly, if it manages to be more > correct than Hadrian (working on GHC every couple of week was a frustrating > experience, with Hadrian easily entering inconsistent state which required > cleaning the entire build and restarting from scratch most every time). > > On the other hand (I have way too much to say about this topic, > evidently), the likely need to require a specific version of Buck2 is not > great for an open source software. For those (like me) who have everything > in Nix development shells it doesn't matter, but most people still use > globally installed tools, and if two open source projects they contribute > require two different versions of Buck2, then they have a problem. Bazel > has the same issue, I think it's a consequence of projects being primarily > built by their respective companies for their internal use where backward > compatibility isn't much of an issue: those who release the new version of > Buck2 simply update the Starlark code in the company's monorepo at the same > time. > > PS: I'm amused by the omnipresence of Neil Mitchell in GHC's build > systems. Tip of the hat to you Neil. > > /Arnaud > > > On Mon, Oct 19, 2026 at 7:10 PM Andreas Klebinger via ghc-devs < > [email protected]> wrote: > > > I'm curious about this. I don't think I ever cared *that* much about the > no-op time. > > I cared a little a few weeks back and found ways to make hadrians no-op > runtime ~25% shorter in relatively little time. > Little enough time to have a suspicion others also don't care all that > much ;-) And there is still low hanging fruit left to pluck. > > I would be more curious about experiences people have with packaging > software using buck2. As that has been a pain point > that come up repeatedly over the years. That being said not sure if > packagers would more happy to see hadrian go, or annoyed > to have to adjust how to package ghc yet again. > On 19/10/2026 16:35, Sebastian Graf via ghc-devs wrote: > > Great!! FWIW, I would be more than happy to adjust to some inconveniences > if no-ops become this cheap again. > > Am Mo., 19. Okt. 2026 um 16:18 Uhr schrieb Simon Marlow < > [email protected]>: > > On Mon, 19 Oct 2026 at 15:12, Sebastian Graf <[email protected]> wrote: > > Hi Simon, > > Thanks for doing this. If my suspicion is correct and the time it takes to > do no-op rebuilds / single test runs is just half as slow as with hadrian, > then this will improve the manual development experience on GHC a lot. Not > that I'm building GHC much these days, much less so manually... > > > No-op rebuild: > > - Hadrian: 7.36s > - Buck2: 0.02s > > caveats apply, Hadrian is also checking the .cabal files for changes > whereas with Buck2 you currently have to re-run ./generate-buck2.hs if you > modify a .cabal file. > > Cheers > Simon > > > > Cheers, > Sebastian > > 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] > > > > -- > brandon s allbery kf8nh > [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]
