Hugs' build system

[Ross Paterson]

On Sun, Feb 25, 2007 at 01:46:26PM +0100, Sven Panne wrote:
>    * 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.

Most of the Hugs packagers have been using version numbers like 200609
for some time now, so we ought not to move to small numbers.

>    * 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.

That's just the RPM path, so feel free.  The rest of us are just using
make to build in place.

> 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).

For releases, I think Hugs should move away from fetching snapshots of
libraries and tools from repositories, and use tarballs of numbered
releases instead, now that we have a home for those.  For library
development, I find it convenient to share a single copy of the library
sources between GHC and Hugs builds.

>    * 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).

No objection, but I think it takes a bit of extra effort to make the
history look nice, e.g. check

	http://darcs.haskell.org/darcsweb/darcsweb.cgi?r=parsec;a=summary