Hi,
as Arch Linux packages GHC and I have experience with it up to and
including 9.14, I'd like to provide my view on what a build system
requires for a good packaging experience.
That being the ability of a build system to build several versions of
GHC while supporting a broad range of dependency versions.
Not having to update both the build system and GHC simultaneously makes
updates much easier, because the individual updates are smaller in scope.
Kind regards,
Vekhir
On Mon, 19 Oct 2026 at 23: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 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 [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 [email protected]
_______________________________________________
ghc-devs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
