Friends | > I see more and more workarounds for workarounds for an unmaintainable | > (and unusable) build system, and after the latest discussions about | > git vs. darcs, maintaining GHC-specific branches of libraries etc., | > I think I'll just drop maintainership from all GHC-related OpenBSD | > ports until the GHC build system chaos settles down a little bit. | | Ian, please read this. | The inability to build GHC reliably is a problem. | | Can someone with a plan please describe what measures are in place | to ensure GHC emerges buildable, and the tree regains the status of a | tree that *does not break*?
I don't think we should over-react here. There's been lots of email on this thread, some of which IMHO makes things sound rather worse than they really are. Let me say how it looks to me. There are two separate but loosely-related conversations going on. 1. Changes to GHC's build system. Cabal is used to build Haskell libraries. We started to use it to build the libraries that come with GHC; and we recently moved over to Cabal to build GHC itself (which is, these days, just another library). The old makefile-based system was essentially duplicating much of the functionality of Cabal, and that duplication was painful. In retrospect, we should have made this change in a branch, and tested it thoroughly before applying it to the HEAD. Build systems tend to be platform dependent, so testing on one platform isn't enough. Nor did we consult, or even communicate, enough before going ahead. And we need more Wiki documentation about how to drive the new system. The net effect of these omissions has been a lot of pain to our collaborators. I am very sorry about that. But I think it'd be a pity to confuse the pain of transition with the destination. The build system is settling down. For the moment, it probably makes sense not to aggressively pull patches from the GHC repo if you don't have to, but we absolutely do not expect that situation to persist. We'll make an announcement when we're ready for you to give it a try. The clear goal is: it simply builds flawlessly. There is an element of "dogfoooding" here. GHC is a stress test for what Cabal can do, and is itself not fully mature. But the pain we experience thereby leads to bug-fixes and significant features for Cabal that are useful for everyone. Perhaps we made the move too early though! The new design is not set in stone, and we are actively thinking about ways to improve it, *including* backing off from Cabal in places where it appears too inflexible. Of course, any such further changes would extend the period of upheaval, but (a) we'll publish a design before executing, and (b) we'll do it on a branch. 2. The version control system (VCS) At the same time, we had an extended conversation about changing the version control system we use for GHC. There was a lot of consultation here, as a result of which we chose git. I won't rehearse again the reasons we are unhappy with darcs, except to say that darcs is a thing of beauty, but the scale of GHC's repository seems to flush out many darcs bugs and performance problems that have proved difficult to fix. Unlike the build system, we have not yet executed this decision. In particular, the earlier discussions focused mainly on the relative merits of the various systems. But it's more complicated than that. GHC needs "core libraries" without which it cannot be built. It is obviously highly desirable that a developer can build GHC with just one VCS, which suggests that the core libraries should be in git too. But those same core libraries are used by nhc98 and Hugs (I think that's all), and the last thing we want to do is to impose new costs on other implementations. Diversity in implementation is a Good Thing. It's unclear exactly what to do about this. The most plausible possibility is to keep the core libraries that are shared with other implementations in darcs as now, and mirror them in git for GHC developers. That will impose pain on GHC developers to keep the git stuff in sync with the darcs master copies; but at least other developers would be unaffected. It's a hard judgement call to say which pain is greatest: the pain of staying with darcs, or the pain of managing the two-VCS problem. Regardless, though, if all you want to do is build GHC from scratch, it absolutely will be a question of getting the relevant VCS, installing support software (Happy, Alex, an earlier GHC), and typing 'make'. You won't have to know about funny branches. We (GHC HQ) are still learning the transition to wider participation in building and hacking on GHC, which we *very much* welcome. Bear with us if we don't get it right first time. We're trying! Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
