Hadrian status

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Hadrian status

Ben Gamari-3
Hi Andrey,

Given that 8.2.1 is finally starting to come together, now is probably a
good time to start reflecting on what will come in 8.4. I think it would
be great if we could finally get Hadrian into the tree for the 8.4
release. It would be even better if we could flip over to Hadrian as the
primary build system. However, if we are to do this then I think we
should leave plenty of time to iron out the inevitable bugs that will
arise.

Have you given much thought to the schedule post-8.2? Do you think a
complete switch-over will be feasible?

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Hadrian status

Andrey Mokhov
Hi Ben and all,

I'm strongly in favour of switching GHC to Hadrian as soon as possible, because just keeping up with changes in GHC takes substantial effort. Zhen Zhang (in CC) has been recently helping me, and I hope he could make good progress towards this goal as part of his Summer of Haskell project (I believe he submitted an application).

Switching will likely be a painful process for GHC developers, because some of the usual workflows will inevitably break. We could keep both Make and Hadrian in the tree for some period of time, but maintaining two completely different build systems is only feasible for a short period of time.

Ben,

Could I ask you to go through the open issues (https://github.com/snowleopard/hadrian/issues) and tag them with the 'tree-tremble' milestone if you think they must be implemented before the merge? I don't hack on GHC myself, so it's often difficult for me to judge the relative importance of features; it would be great if you could also tag the issues with priorities (I've just created tags high-/medium-/low-priority).

Everyone:

Please contribute to the discussions on the minimum set of features that Hadrian should support before it can replace Make in this thread: https://github.com/snowleopard/hadrian/issues/239.
 
Cheers,
Andrey

-----Original Message-----
From: Ben Gamari [mailto:[hidden email]]
Sent: 09 May 2017 21:37
To: Andrey Mokhov <[hidden email]>
Cc: GHC developers <[hidden email]>
Subject: Hadrian status

Hi Andrey,

Given that 8.2.1 is finally starting to come together, now is probably a
good time to start reflecting on what will come in 8.4. I think it would
be great if we could finally get Hadrian into the tree for the 8.4
release. It would be even better if we could flip over to Hadrian as the
primary build system. However, if we are to do this then I think we
should leave plenty of time to iron out the inevitable bugs that will
arise.

Have you given much thought to the schedule post-8.2? Do you think a
complete switch-over will be feasible?

Cheers,

- Ben
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Hadrian status

Ben Gamari-3
Andrey Mokhov <[hidden email]> writes:

> Hi Ben and all,
>
> I'm strongly in favour of switching GHC to Hadrian as soon as
> possible, because just keeping up with changes in GHC takes
> substantial effort.

I can imagine; I feel like there has been even more build system churn
in GHC than usually recently.

> Zhen Zhang (in CC) has been recently helping me, and I hope he could
> make good progress towards this goal as part of his Summer of Haskell
> project (I believe he submitted an application).
>
Great, thanks for your effort Zhen!

> Switching will likely be a painful process for GHC developers, because
> some of the usual workflows will inevitably break. We could keep both
> Make and Hadrian in the tree for some period of time, but maintaining
> two completely different build systems is only feasible for a short
> period of time.
>
I agree; ideally we will have switched over fully to Hadrian before the
8.4 release.

> Could I ask you to go through the open issues
> (https://github.com/snowleopard/hadrian/issues) and tag them with the
> 'tree-tremble' milestone if you think they must be implemented before
> the merge? I don't hack on GHC myself, so it's often difficult for me
> to judge the relative importance of features; it would be great if you
> could also tag the issues with priorities (I've just created tags
> high-/medium-/low-priority).
>
I had a pass over the issues. The two things that stood out to me above
all are

 * #250 (freezing stage 1): This is something that most GHC developers
   use on a daily basis. Working on GHC without this feature would be
   painful indeed.

 * #308 (document on debugging Hadrian): It will almost certainly be the
   case that developers will eventually encounter issues. If we have
   document describing how to start digging into these issues we will be
   less dependent on scarce resources such as yourself.

I've marked these as high priority, milestoned to Tree Tremble.

It would also be great to have #187 (validation support) resolved so we
can start integration with GHC's CI infrastructure.

I've also milestoned a number of things to ghc-quake,

 * #178 (LLVM toolchain)
 * #248 (Fix dynamicGhcPrograms)
 * #246 (build user's guide and man pages)

I think that should pretty much cover it.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Loading...