Replacing Hadrian with Buck2
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
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... Cheers, Sebastian Am Mo., 19. Okt. 2026 um 16:07 Uhr schrieb Simon Marlow via ghc-devs < ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
On Mon, 19 Oct 2026 at 15:12, Sebastian Graf <sgraf1337@gmail.com> 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 < ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
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 <marlowsd@gmail.com
:
On Mon, 19 Oct 2026 at 15:12, Sebastian Graf <sgraf1337@gmail.com> 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 < ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
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 <marlowsd@gmail.com>:
On Mon, 19 Oct 2026 at 15:12, Sebastian Graf <sgraf1337@gmail.com> 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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org
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 < ghc-devs@haskell.org> 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 < marlowsd@gmail.com>:
On Mon, 19 Oct 2026 at 15:12, Sebastian Graf <sgraf1337@gmail.com> 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 < ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- brandon s allbery kf8nh allbery.b@gmail.com
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 <ghc-devs@haskell.org> 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 <marlowsd@gmail.com>:
On Mon, 19 Oct 2026 at 15:12, Sebastian Graf <sgraf1337@gmail.com> 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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
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 <arnaud@spiwack.net> 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 < ghc-devs@haskell.org> 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 < marlowsd@gmail.com>:
On Mon, 19 Oct 2026 at 15:12, Sebastian Graf <sgraf1337@gmail.com> 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 < ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- brandon s allbery kf8nh allbery.b@gmail.com
On Tue, 20 Oct 2026 at 01:29, Arnaud Spiwack via ghc-devs < ghc-devs@haskell.org> 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 < ghc-devs@haskell.org> 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 < marlowsd@gmail.com>:
On Mon, 19 Oct 2026 at 15:12, Sebastian Graf <sgraf1337@gmail.com> 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 < ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Brandon Allbery via ghc-devs <ghc-devs@haskell.org> writes:
FWIW what I've heard from packagers over the years is that Hadrian is an unwanted pain point for them.
While I have heard similar things about Hadrian, it does not seem to me that Buck2 is going to be better in this regard. While I am certain that Buck2 has many merits, as far as I can tell it is not maintained in a way to make it easy to consume by open-source packagers or potential dependees: * The project does not appear to have a versioning scheme beyond datestamps * as far as I can tell there are no formal release notes or changelogs provided; CHANGELOG.md is, amusingly, only 28 bytes long containing the string "- Initial version" * the GitHub release artifacts [1] themselves are a collection of files with neither descriptions nor, in many cases, file extensions * it appears [2] that there is currently no formal release process and the recommended practice appears to be use the tip of `main` This does not strike me as the sort of package you would want to take as a dependency outside of a monorepo. As far as I can tell, the only packaging of Buck2 provided with a formal OS distribution is in `nixpkgs`. I think that this is quite symptomatic of the problem. All of this is to say that Buck2 isn't something that I would feel comfortable telling GHC's packagers that they need to package and consume. It is already hard enough to get people to package a compiler like GHC; then demanded that they *also* package a build system which isn't maintained in a FOSS-friendly manner is only going to exacerbate this problem. Naturally, this could change if Buck2's maintenance changes. However, until then I would be opposed to going this direction regardless of whatever merits the build system itself might offer. Cheers, - Ben [2] https://github.com/facebook/buck2#-warning---rough-terrain-lies-ahead
On Tue, 20 Oct 2026 at 02:48, Ben Gamari via ghc-devs <ghc-devs@haskell.org> wrote:
Brandon Allbery via ghc-devs <ghc-devs@haskell.org> writes:
FWIW what I've heard from packagers over the years is that Hadrian is an unwanted pain point for them.
While I have heard similar things about Hadrian, it does not seem to me that Buck2 is going to be better in this regard. While I am certain that Buck2 has many merits, as far as I can tell it is not maintained in a way to make it easy to consume by open-source packagers or potential dependees:
* The project does not appear to have a versioning scheme beyond datestamps
* as far as I can tell there are no formal release notes or changelogs provided; CHANGELOG.md is, amusingly, only 28 bytes long containing the string "- Initial version"
* the GitHub release artifacts [1] themselves are a collection of files with neither descriptions nor, in many cases, file extensions
* it appears [2] that there is currently no formal release process and the recommended practice appears to be use the tip of `main`
This is a reasonable criticism. The way I imagine it working: * Each GHC release pins a compatible Buck2 release, much like a submodule. Perhaps we treat Buck2 as a purely local build tool and have `./boot` fetch it (it's just a binary). * From time to time we move GHC master to Buck2 latest, which involves merging upstream changes to the Buck2 prelude into our Buck2 prelude. We might only do this once per major GHC release, or something like that. My plan is to upstream the local changes as much as possible so that this process is easy, and I've been trying to keep the local changes to a minimum. So then we are in full control of the dependency, and the only risks are (a) old binaries going away (we could check them into the GHC repo if that was an issue) and (b) lagging too far behind upstream so that merging became difficult, or upstream making some prelude changes that break our build and are hard to fix. It's not as smooth as depending on a well-packaged build tool, but it's manageable I think. I'd like to understand more about what difficulties packagers have with Hadrian. I've run into this a little with integrating GHC into Meta's build system, and in that case the problems were: * dependencies: Hadrian had more dependencies than `make` did previously which made bootstrapping a GHC build harder (I think Buck2 is neither better nor worse than Hadrian here) * configuring the build system: adding flags and build settings from the environment was hard * installing things in the right places Ultimately I think the build output should be just a file tree that you can unpack anywhere and use, and that will make things simpler for packagers. Ideally we want to make the interface between packagers and the GHC build system as narrow as possible, so that we could change the build system without breaking packagers. Cheers Simon
I'd like to understand more about what difficulties packagers have with Hadrian.
I can only speak for packaging ghc in haskell.nix. - non-standard bespoke (make, cmake) build system. - a moving build system that changes over time how things work. - obscure edge cases breaking (stage1 cross ghc installation), cross compilers, … - bisecting being hard because the build system and compiler are symbiotic. And then of course the fact that it’s basically a custom cabal-install, but only half way there. E.g. duplicate effort, but still bespoke, and then some custom symbiotic logic encoded in the build system specifically for this one compiler (-version). That’s also the reason why stable-haskell cabalized everything. To properly get stage1/stage2 support we had to add cross compiler support to cabal (boot is the build compiler for stage1, stage1 is the build compiler for stage2, similar to how a native compiler is the build compiler for a cross compiler). I think what would be nice would be if cabal could be the cabal project -> buck project translator. That would allow any generic cabal project (e.g. ghc) to be buildable via buck. Best, Moritz
On Tue, 20 Oct 2026 at 10:33, Moritz Angermann <moritz.angermann@gmail.com> wrote:
I think what would be nice would be if cabal could be the cabal project -> buck project translator. That would allow any generic cabal project (e.g. ghc) to be buildable via buck.
I mean, that's pretty much what I've done :-) The Buck2 build system is based on https://hackage.haskell.org/package/cabal-buck2 The differences between a generic Cabal project and GHC amount to (currently) 1400 lines of extra stuff. I'd say most of this is to deal with stages, the RTS, and building a GHC libdir. I think that's quite reasonable, there's a limit to how much GHC-specific stuff you would want to move into Cabal. Cheers Simon
I think what would be nice would be if cabal could be the cabal project -> buck project translator. That would allow any generic cabal project (e.g. ghc) to be buildable via buck.
I mean, that's pretty much what I've done :-) The Buck2 build system is based on https://hackage.haskell.org/package/cabal-buck2
The differences between a generic Cabal project and GHC amount to (currently) 1400 lines of extra stuff. I'd say most of this is to deal with stages, the RTS, and building a GHC libdir. I think that's quite reasonable, there's a limit to how much GHC-specific stuff you would want to move into Cabal.
I fully agree. None. Teach cabal about stages is worth it simply because it allows cabal to also work for cross compilers properly. (setup.hs, and similar need to be built by a differnt compiler than your actual library/executable). So this work is adding generic support, which then just happens making GHC buildable. And that’s not some hypothetical. The GitHub.com/stable-haskell/ghc builds with a slightly modified cabal-install today. Yes there is some rejigging of the it’s, but it’s expressible and buildable with a cabal-install with dual compiler (build and host) support, today. I’m trying to get Andrea to take interest in the cabal-buck2 project 😅
Hi All, I think I agree with Ben's sentiment here, there's quite the high barrier to adopting a new third party build system, that is not surpassed by downloading a binary in `./boot`. I think the first barrier to clear is asking all packagers that are shipping GHC in their repos if they'd even be willing to package buck2. To me it appears that a project that seems more like a source available internal product than a free and open source software that doesn't have any maintenance guarantee or versioning scheme is something that most packagers won't package, and they for sure won't do that just to keep shipping GHC. Most packagers are unpaid volunteers who would really like to avoid churn. They are also our gateway of having GHC be actually used by most people. There should be a VERY good reason for us to cause such immense churn as using buck2 as GHC's build system would be. I don't think any of the already named reasons qualify. I also think that moving GHC even further away from being "bootstrappable" in any reasonable sense of the word by requiring a third party's binary to be downloaded (are there buck2 binaries that work on FreeBSD? MacOS x86? PowerPC? alpine linux i386? loongarch?) to even start building it is not a good trajectory. That being said, I think it's nice to have more ways to build GHC! If the buck2 build of GHC will just live outside of the GHC tree and just gets updated so that companies who regularly build GHC with their patches or even contributors who like it better than hadrian can use it, that would be great! I just don't think that it should become the liability of the GHC maintainers or downstream packagers. Best Magnus On 10/20/26 03:48, Ben Gamari via ghc-devs wrote:
Brandon Allbery via ghc-devs <ghc-devs@haskell.org> writes:
FWIW what I've heard from packagers over the years is that Hadrian is an unwanted pain point for them.
While I have heard similar things about Hadrian, it does not seem to me that Buck2 is going to be better in this regard. While I am certain that Buck2 has many merits, as far as I can tell it is not maintained in a way to make it easy to consume by open-source packagers or potential dependees:
* The project does not appear to have a versioning scheme beyond datestamps
* as far as I can tell there are no formal release notes or changelogs provided; CHANGELOG.md is, amusingly, only 28 bytes long containing the string "- Initial version"
* the GitHub release artifacts [1] themselves are a collection of files with neither descriptions nor, in many cases, file extensions
* it appears [2] that there is currently no formal release process and the recommended practice appears to be use the tip of `main`
This does not strike me as the sort of package you would want to take as a dependency outside of a monorepo. As far as I can tell, the only packaging of Buck2 provided with a formal OS distribution is in `nixpkgs`. I think that this is quite symptomatic of the problem.
All of this is to say that Buck2 isn't something that I would feel comfortable telling GHC's packagers that they need to package and consume. It is already hard enough to get people to package a compiler like GHC; then demanded that they *also* package a build system which isn't maintained in a FOSS-friendly manner is only going to exacerbate this problem.
Naturally, this could change if Buck2's maintenance changes. However, until then I would be opposed to going this direction regardless of whatever merits the build system itself might offer.
Cheers,
- Ben
[2] https://github.com/facebook/buck2#-warning---rough-terrain-lies-ahead
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
These are reasonable concerns, but let's not forget the current situation is far from ideal: Hadrian is large, complicated, slow, unsound, bespoke, and depends on a semi-maintained build system itself (Shake). Speaking for myself, Hadrian puts me off working on GHC which is partly why the first thing I'm doing to get back into GHC development is to replace the build system with one I like 😁. An unergonomic build system is a drag on development and deters contributions. 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? Cheers Simon On Tue, 20 Oct 2026 at 12:58, Magnus Viernickel via ghc-devs < ghc-devs@haskell.org> wrote:
Hi All,
I think I agree with Ben's sentiment here, there's quite the high barrier to adopting a new third party build system, that is not surpassed by downloading a binary in `./boot`.
I think the first barrier to clear is asking all packagers that are shipping GHC in their repos if they'd even be willing to package buck2. To me it appears that a project that seems more like a source available internal product than a free and open source software that doesn't have any maintenance guarantee or versioning scheme is something that most packagers won't package, and they for sure won't do that just to keep shipping GHC. Most packagers are unpaid volunteers who would really like to avoid churn. They are also our gateway of having GHC be actually used by most people. There should be a VERY good reason for us to cause such immense churn as using buck2 as GHC's build system would be. I don't think any of the already named reasons qualify.
I also think that moving GHC even further away from being "bootstrappable" in any reasonable sense of the word by requiring a third party's binary to be downloaded (are there buck2 binaries that work on FreeBSD? MacOS x86? PowerPC? alpine linux i386? loongarch?) to even start building it is not a good trajectory.
That being said, I think it's nice to have more ways to build GHC! If the buck2 build of GHC will just live outside of the GHC tree and just gets updated so that companies who regularly build GHC with their patches or even contributors who like it better than hadrian can use it, that would be great!
I just don't think that it should become the liability of the GHC maintainers or downstream packagers.
Best
Magnus
On 10/20/26 03:48, Ben Gamari via ghc-devs wrote:
Brandon Allbery via ghc-devs <ghc-devs@haskell.org> writes:
FWIW what I've heard from packagers over the years is that Hadrian is an unwanted pain point for them.
While I have heard similar things about Hadrian, it does not seem to me that Buck2 is going to be better in this regard. While I am certain that Buck2 has many merits, as far as I can tell it is not maintained in a way to make it easy to consume by open-source packagers or potential dependees:
* The project does not appear to have a versioning scheme beyond datestamps
* as far as I can tell there are no formal release notes or changelogs provided; CHANGELOG.md is, amusingly, only 28 bytes long containing the string "- Initial version"
* the GitHub release artifacts [1] themselves are a collection of files with neither descriptions nor, in many cases, file extensions
* it appears [2] that there is currently no formal release process and the recommended practice appears to be use the tip of `main`
This does not strike me as the sort of package you would want to take as a dependency outside of a monorepo. As far as I can tell, the only packaging of Buck2 provided with a formal OS distribution is in `nixpkgs`. I think that this is quite symptomatic of the problem.
All of this is to say that Buck2 isn't something that I would feel comfortable telling GHC's packagers that they need to package and consume. It is already hard enough to get people to package a compiler like GHC; then demanded that they *also* package a build system which isn't maintained in a FOSS-friendly manner is only going to exacerbate this problem.
Naturally, this could change if Buck2's maintenance changes. However, until then I would be opposed to going this direction regardless of whatever merits the build system itself might offer.
Cheers,
- Ben
[2] https://github.com/facebook/buck2#-warning---rough-terrain-lies-ahead
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
I can comment on the distribution part quite confidently: 1. If GHC is going to require 3rd party binaries (like buck2) for bootstrapping, it probably won't make major distributions drop it, but there's a fair chance smaller distros will and the migration may be costly for the rest and cause delayed updates. Even Gentoo, which has historically packaged all sorts of esoteric build systems, does not package buck2. BSD does neither and there are no upstream binaries. 2. While trying to include buck2 in ghcup (https://codeberg.org/haskell/ghcup-hs/issues/1401), I was also rather offput by the lack of proper versioning scheme and everything being prereleases. Maybe this is the way with modern git and AI development, but I'm not sure how I, as a distributor, am going to judge which one is a usable/good/stable release. Sure, I could try to absorb all of those issues in ghcup... figure out what releases are usable, clean up their build artifacts, build on freebsd and other platforms that GHC supports... but I'm not sure this is a good use of my time. If buck2 is opt-in... then all those problems are not very hard. Power users can use it anyhow. On Tue, 2026-10-20 at 13:58 +0200, Magnus Viernickel via ghc-devs wrote:
Hi All,
I think I agree with Ben's sentiment here, there's quite the high barrier to adopting a new third party build system, that is not surpassed by downloading a binary in `./boot`.
I think the first barrier to clear is asking all packagers that are shipping GHC in their repos if they'd even be willing to package buck2. To me it appears that a project that seems more like a source available internal product than a free and open source software that doesn't have any maintenance guarantee or versioning scheme is something that most packagers won't package, and they for sure won't do that just to keep shipping GHC. Most packagers are unpaid volunteers who would really like to avoid churn. They are also our gateway of having GHC be actually used by most people. There should be a VERY good reason for us to cause such immense churn as using buck2 as GHC's build system would be. I don't think any of the already named reasons qualify.
I also think that moving GHC even further away from being "bootstrappable" in any reasonable sense of the word by requiring a third party's binary to be downloaded (are there buck2 binaries that work on FreeBSD? MacOS x86? PowerPC? alpine linux i386? loongarch?) to even start building it is not a good trajectory.
That being said, I think it's nice to have more ways to build GHC! If the buck2 build of GHC will just live outside of the GHC tree and just gets updated so that companies who regularly build GHC with their patches or even contributors who like it better than hadrian can use it, that would be great!
I just don't think that it should become the liability of the GHC maintainers or downstream packagers.
Best
Magnus
On 10/20/26 03:48, Ben Gamari via ghc-devs wrote:
Brandon Allbery via ghc-devs <ghc-devs@haskell.org> writes:
FWIW what I've heard from packagers over the years is that Hadrian is an unwanted pain point for them.
While I have heard similar things about Hadrian, it does not seem to me that Buck2 is going to be better in this regard. While I am certain that Buck2 has many merits, as far as I can tell it is not maintained in a way to make it easy to consume by open-source packagers or potential dependees:
* The project does not appear to have a versioning scheme beyond datestamps
* as far as I can tell there are no formal release notes or changelogs provided; CHANGELOG.md is, amusingly, only 28 bytes long containing the string "- Initial version"
* the GitHub release artifacts [1] themselves are a collection of files with neither descriptions nor, in many cases, file extensions
* it appears [2] that there is currently no formal release process and the recommended practice appears to be use the tip of `main`
This does not strike me as the sort of package you would want to take as a dependency outside of a monorepo. As far as I can tell, the only packaging of Buck2 provided with a formal OS distribution is in `nixpkgs`. I think that this is quite symptomatic of the problem.
All of this is to say that Buck2 isn't something that I would feel comfortable telling GHC's packagers that they need to package and consume. It is already hard enough to get people to package a compiler like GHC; then demanded that they *also* package a build system which isn't maintained in a FOSS-friendly manner is only going to exacerbate this problem.
Naturally, this could change if Buck2's maintenance changes. However, until then I would be opposed to going this direction regardless of whatever merits the build system itself might offer.
Cheers,
- Ben
[2] https://github.com/facebook/buck2#-warning---rough-terrain-lies-ahead
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Rolling release has become all the rage, sadly. On Wed, Oct 21, 2026 at 12:46 AM Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
I can comment on the distribution part quite confidently:
1. If GHC is going to require 3rd party binaries (like buck2) for bootstrapping, it probably won't make major distributions drop it, but there's a fair chance smaller distros will and the migration may be costly for the rest and cause delayed updates. Even Gentoo, which has historically packaged all sorts of esoteric build systems, does not package buck2. BSD does neither and there are no upstream binaries.
2. While trying to include buck2 in ghcup (https://codeberg.org/haskell/ghcup-hs/issues/1401), I was also rather offput by the lack of proper versioning scheme and everything being prereleases. Maybe this is the way with modern git and AI development, but I'm not sure how I, as a distributor, am going to judge which one is a usable/good/stable release.
Sure, I could try to absorb all of those issues in ghcup... figure out what releases are usable, clean up their build artifacts, build on freebsd and other platforms that GHC supports... but I'm not sure this is a good use of my time.
If buck2 is opt-in... then all those problems are not very hard. Power users can use it anyhow.
On Tue, 2026-10-20 at 13:58 +0200, Magnus Viernickel via ghc-devs wrote:
Hi All,
I think I agree with Ben's sentiment here, there's quite the high barrier to adopting a new third party build system, that is not surpassed by downloading a binary in `./boot`.
I think the first barrier to clear is asking all packagers that are shipping GHC in their repos if they'd even be willing to package buck2. To me it appears that a project that seems more like a source available internal product than a free and open source software that doesn't have any maintenance guarantee or versioning scheme is something that most packagers won't package, and they for sure won't do that just to keep shipping GHC. Most packagers are unpaid volunteers who would really like to avoid churn. They are also our gateway of having GHC be actually used by most people. There should be a VERY good reason for us to cause such immense churn as using buck2 as GHC's build system would be. I don't think any of the already named reasons qualify.
I also think that moving GHC even further away from being "bootstrappable" in any reasonable sense of the word by requiring a third party's binary to be downloaded (are there buck2 binaries that work on FreeBSD? MacOS x86? PowerPC? alpine linux i386? loongarch?) to even start building it is not a good trajectory.
That being said, I think it's nice to have more ways to build GHC! If the buck2 build of GHC will just live outside of the GHC tree and just gets updated so that companies who regularly build GHC with their patches or even contributors who like it better than hadrian can use it, that would be great!
I just don't think that it should become the liability of the GHC maintainers or downstream packagers.
Best
Magnus
On 10/20/26 03:48, Ben Gamari via ghc-devs wrote:
Brandon Allbery via ghc-devs <ghc-devs@haskell.org> writes:
FWIW what I've heard from packagers over the years is that Hadrian is an unwanted pain point for them.
While I have heard similar things about Hadrian, it does not seem to me that Buck2 is going to be better in this regard. While I am certain that Buck2 has many merits, as far as I can tell it is not maintained in a way to make it easy to consume by open-source packagers or potential dependees:
* The project does not appear to have a versioning scheme beyond datestamps
* as far as I can tell there are no formal release notes or changelogs provided; CHANGELOG.md is, amusingly, only 28 bytes long containing the string "- Initial version"
* the GitHub release artifacts [1] themselves are a collection of files with neither descriptions nor, in many cases, file extensions
* it appears [2] that there is currently no formal release process and the recommended practice appears to be use the tip of `main`
This does not strike me as the sort of package you would want to take as a dependency outside of a monorepo. As far as I can tell, the only packaging of Buck2 provided with a formal OS distribution is in `nixpkgs`. I think that this is quite symptomatic of the problem.
All of this is to say that Buck2 isn't something that I would feel comfortable telling GHC's packagers that they need to package and consume. It is already hard enough to get people to package a compiler like GHC; then demanded that they *also* package a build system which isn't maintained in a FOSS-friendly manner is only going to exacerbate this problem.
Naturally, this could change if Buck2's maintenance changes. However, until then I would be opposed to going this direction regardless of whatever merits the build system itself might offer.
Cheers,
- Ben
[2] https://github.com/facebook/buck2#-warning---rough-terrain-lies-ahead
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- brandon s allbery kf8nh allbery.b@gmail.com
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 <ghc-devs@haskell.org> 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 <marlowsd@gmail.com>:
On Mon, 19 Oct 2026 at 15:12, Sebastian Graf <sgraf1337@gmail.com> 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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- brandon s allbery kf8nh allbery.b@gmail.com
_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org
In my experience Hadrian is kind of confusing and simply lacks a _lot_ of polish. I think its an impediment to new contributors. I've started working on it (e.g. https://github.com/ndmitchell/shake/pull/862), but I wouldn't be sad if its replaced by something else. In particular I would hope that if we adopt buck2 or some other build system that is more to your liking, 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? Am Mo., 19. Okt. 2026 um 16:07 Uhr schrieb Simon Marlow via ghc-devs <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
On Tue, 20 Oct 2026 at 15:40, Simon Jakobi <simon.jakobi@gmail.com> 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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
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 < ghc-devs@haskell.org> wrote:
On Tue, 20 Oct 2026 at 15:40, Simon Jakobi <simon.jakobi@gmail.com> 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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
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? 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 <ghc-devs@haskell.org> wrote:
On Tue, 20 Oct 2026 at 15:40, Simon Jakobi <simon.jakobi@gmail.com> 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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
On Wed, 21 Oct 2026 at 06:15, Julian Ospald via ghc-devs < ghc-devs@haskell.org> 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 <ghc-devs@haskell.org> wrote:
On Tue, 20 Oct 2026 at 15:40, Simon Jakobi <simon.jakobi@gmail.com> 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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
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 < ghc-devs@haskell.org> wrote:
On Wed, 21 Oct 2026 at 06:15, Julian Ospald via ghc-devs < ghc-devs@haskell.org> 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 <ghc-devs@haskell.org> wrote:
On Tue, 20 Oct 2026 at 15:40, Simon Jakobi <simon.jakobi@gmail.com> 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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- brandon s allbery kf8nh allbery.b@gmail.com
On Wed, 21 Oct 2026 at 11:29, Brandon Allbery <allbery.b@gmail.com> wrote:
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!
Well yes, but that's for *invoking* GHC, not for *building* GHC. You wouldn't want special-case support in Cabal for building exactly one specific project, even if it is quite an important one.
On Wed, Oct 21, 2026 at 4:32 AM Simon Marlow via ghc-devs < ghc-devs@haskell.org> wrote:
On Wed, 21 Oct 2026 at 06:15, Julian Ospald via ghc-devs < ghc-devs@haskell.org> 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 <ghc-devs@haskell.org> wrote:
On Tue, 20 Oct 2026 at 15:40, Simon Jakobi <simon.jakobi@gmail.com> 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 <ghc-devs@haskell.org>: > > 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 -- ghc-devs@haskell.org > To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- brandon s allbery kf8nh allbery.b@gmail.com
Sure... just to be clear: our goal is definitely to *decouple* GHC and cabal, not make them more intertwined! It just so happens that lots of things that you need in order to build GHC with cabal... happen to be generic problems in our view: * per-file (or even per-function) compilation flags... I'm afraid I can't find the GHC ticket right now * proper cross compilation support with a staged solver (https://github.com/haskell/cabal/pull/12356) * any interface at all to do something useful with the build artifacts that is NOT merging them to the filesystem (e.g. creating a bindist or use a custom merger) There may be things that will still require some glue code, but our goal is definitely to be able to do `cabal install ghc` and have it compile a stage1, then a stage2 ghc and install it nicely, without GHC- specific features in cabal. Yes, that may not be the workflow that GHC devs need, but it will anyhow reduce the need for glue code. Maybe we can simply delete most of hadrian once this is possible and just keep those parts that are truly GHC specific. You can reach out to us on the discord: https://discord.gg/NekCNkCeJ I also gave a presentation last ZuriHac: https://youtu.be/BtTaT90OvPE?si=2BGJb_f9Ck4TcT63 The code is here: * https://github.com/stable-haskell/cabal * https://github.com/stable-haskell/ghc Cheers, Julian On Wed, 2026-10-21 at 09:32 +0100, Simon Marlow via ghc-devs wrote:
On Wed, 21 Oct 2026 at 06:15, Julian Ospald via ghc-devs <ghc-devs@haskell.org> 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 <ghc-devs@haskell.org> wrote:
On Tue, 20 Oct 2026 at 15:40, Simon Jakobi <simon.jakobi@gmail.com> 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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
participants (11)
-
Andreas Klebinger -
Arnaud Spiwack -
Ben Gamari -
Brandon Allbery -
Julian Ospald -
Magnus Viernickel -
Moritz Angermann -
Sebastian Graf -
Simon Jakobi -
Simon Marlow -
Vekhir