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:ben@well-typed.com]
Sent: 09 May 2017 21:37
To: Andrey Mokhov
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.
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
participants (2)
-
Andrey Mokhov -
Ben Gamari