Hugs' build system

[Sven Panne]

FYI: While trying to fix some issues with Hugs, I came to the conclusion that 
Hugs' build system as it stands today is a bit arcane and might need some 
improvements. The general strategy will be to make things more similar to GHC 
and nhc98:

   * I think we should abandon version names like "Sep2006" and go for the 
usual numerical even/odd numbering scheme. This more consistent with the rest 
of the world and makes it easier for tools to determine e.g. which version is 
newer. I am not sure if we have ever released a numerical version, so I 
propose to call the current version 0.9 (odd, because it is a developer 
version) and bump it to 1.0 for the next release.

   * make and rpmbuild are used the wrong way round for most automated build 
systems, i.e. one should be able to use rpmbuild to build an rpm, and not 
make. Furthermore, configure should determine the version number, not make. I 
propose to use a similar version numbering as GHC, i.e. major.minor.date for 
snapshots and simply major.minor for releases, including the current way of 
e.g. saying 'RELEASE=YES rpmbuild hugs98.spec" to build a release.

   * The current way of checking out things, tar-ing it up, unpacking 
into /tmp and building there is very annoying and I fail to see a good reason 
for this. Let's do it like GHC/nhc98 and use a darcs-all script to check 
out/update all things, so one can e.g. easily copy the whole source tree 
around and get a usable, version controlled build tree without any need for 
network access. While doing this, we can make it very explicit what 
are "core" packages and which are "extra" ones by simply listing them in 
separate files (and not bury this deep inside the Makefile).

   * I think that Hugs should finally be moved to darcs instead of CVS, the 
current mix of version control systems is a bit obscure and we need darcs for 
the libraries, anyway. I have no former experience in doing this conversion, 
but I think others on this list have, so I'd prefer not doing this for myself 
(or at least get some hint/tricks/... from others who have done it before).

I don't know exactly how WinHugs is currently being built, but I guess that 
there are no fundamental reasons why the above changes could seriously break 
WinHugs development. Otherwise: Neil, please yell! :-)

Cheers,
   S.