FWIW what I've heard from packagers over the years is that Hadrian is an unwanted pain point for them.
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]
