Hadrian

Ben Gamari ben at smart-cactus.org
Thu Oct 19 19:11:50 UTC 2017


"Boespflug, Mathieu" <m at tweag.io> writes:

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171019/6d130408/attachment.sig>


More information about the ghc-devs mailing list