On Tue, 20 Oct 2026 at 02:48, Ben Gamari via ghc-devs <[email protected]> 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 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
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
