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 <[email protected]> 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 -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > ghc-devs mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
