"Boespflug, Mathieu"
Hi all,
As a user who tried to be an early adopter of Hadrian, I can attest to Andrey's remarks about GHC progress sometimes (frequently?) breaking Hadrian.
Ben, Andrey - how about this strawman proposal:
we merge Hadrian into GHC *now*, not because ./validate with Hadrian works (it doesn't yet), but because the build of GHC succeeds with Hadrian. The resulting compiler might well be garbage. But that's fine - we can iterate in the official ghc repo, all the while knowing that CI has our back if ever some change makes Hadrian no longer even build a compiler. Once ./validate passes with Hadrian, the guarantee that CI gives will become stronger still: we'll know if any change would make the Hadrian-produced compiler garbage again.
Maybe that does sound totally bonkers to you? :) Maybe it's radical, but sounds to me like the best way to get the benefit *now* of ensuring Make and Hadrian move forward in lock step thanks to CI.
The above all assumes that we're committed to Hadrian being the future of GHC's build system. But I take it that's a given by now.
That's not so different from my existing plan, which is to import Hadrian after 8.2.2. That being said, if it's okay with Andrey to import now then it is also okay with me. There are, of course some details to be worked out: do we import hadrian as a git subtree, retaining history, or simply squash a snapshot? Where should tickets now be filed from now on? Should we move the scripts in the top-level of the hadrian repo to the top-level of the GHC repo? Cheers, - Ben