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 < [email protected]> 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]
