On Tue, 20 Oct 2026 at 01:29, Arnaud Spiwack via ghc-devs < [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? > I should clarify that Buck2 isn't fundamentally hermetic, it's only hermetic if you go to the trouble of installing your entire build toolchain in the local tree and tell Buck2 about it. The way I'm using Buck2, it just uses your installed C and Haskell toolchains, so it's not hermetic. This does mean that using a build cache is more error prone, because you have to figure out how to fingerprint the installed toolchain enough for the cache keys to be unique. There are ways that Buck2 is more correct than Hadrian despite not being hermetic, though: e.g. Buck2 correctly handles changes in the build system itself, while Hadrian doesn't. Cheers Simon > 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] > > _______________________________________________ > 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]
