Version control systems

[Simon Peyton-Jones]

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