Problems building ghc-current

[Simon Marlow]

=20
> "Simon Marlow" <simonmar@microsoft.com> writes:
>=20
> > >     /cvs --+
> > >            |
> > >            +-- CVSROOT
> > >            |
> > >            +-- fptools
> > >            |
> > >            +-- ghc
> > >            |
> > >            +-- libraries
> > >            |
> > >            +-- hslibs
> > >            |
> > >            +-- green-card
> > >          [...]
> >=20
> > We could just rearrange the repository in place, and=20
> everything would
> > still work, right?  Well, perhaps the script that generates the CVS
> > commit logs would have to be tweaked.
>=20
> Don't forget that any scripts/Makefiles that refer to ../something may
> need to change to ../fptools/something.  Examples might include the
> global `mk' files, glafp-utils, and so on.  Of course, those could
> all live at the new toplevel as well, provided that checking out the
> 'fptools' project collected all of them in one operation.

No, the idea is that the source tree structure would remain exactly the
same, it's only the repository that would change.  The checkout
procedure remains almost the same:

  $ cvs co fptools
  $ cd fptools
  $ cvs co ghc hslibs libraries

(except the third step now *must* be 'cvs co', not 'cvs up -d').  The
advantages are that (a) there's no hacky 'fpconfig' module, and (b) 'cvs
update -d' works properly from the top of fptools.

One possible problem is that if we switch to using something less
braindead than CVS (eg. Subversion) at some point in the future, this
structure might cause problems.

Cheers,
	Simon