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]
