Hugs' build system

Sven Panne

25 Feb 2007 25 Feb '07

12:46 p.m.

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.

Show replies by date

Neil Mitchell

25 Feb 25 Feb

1:44 p.m.

...

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

I like Sep2006, I think its cute, and I would actually rather the rest of the world moved to this system. However, I don't care enough to be the person who stops this.

...

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

Definitely! Malcolm Wallace has done this a couple of times, on nhc/Hat and others, and probably knows how to do it well by now.

...

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! :-)

I build the libraries using the makefile combo etc. on Mingw. That stage often breaks, since its rarely tested - anything to make it more reliable would be welcome. To build the libraries I typically delete my CVS tree and do a completely clean checkout, anything else goes wrong even more. I build the executables and installer using a small batch file and calls to Visual Studio - this is very easy, and I'm happy to keep this outside of the main Hugs build logic. Thanks Neil

Sven Panne

1:55 p.m.

On Sunday 25 February 2007 14:44, Neil Mitchell 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.

I like Sep2006, I think its cute, and I would actually rather the rest of the world moved to this system. However, I don't care enough to be the person who stops this. [...]

While I think that versions like "Sep2006" are nicer for humans, I have serious doubts that the tons of SW out there to handle packages (rpm, apt, yum, yast, ... plus probably quite a few home-grown ones) handle such versions correctly. Will all of these programs e.g. consistently determine that "Apr2005" is newer than "Mar2004"? I doubt that, and instead of trying to change the world I simply propose that we follow a common numbering scheme. Perhaps we can revisit this decision in a few years, when the world is a better place... ;-) Cheers, S.

Ross Paterson

4:48 p.m.

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

Malcolm Wallace

5:12 p.m.

Ross Paterson writes:

...

...
* I think that Hugs should finally be moved to darcs instead of CVS

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

This is just a matter of which options you give to 'tailor', the conversion utility. In particular, you can tell it to use the first line of the CVS commit message as the name of the darcs patch, with the remaining lines from CVS as the "long" message in darcs. The main non-automated issue when converting is the need to create/steal a darcs-all script, and maybe a utility to fix executable permissions for fresh checkouts. Regards, Malcolm

Sven Panne

15 Mar 15 Mar

11 a.m.

On Sunday 25 February 2007 18:12, Malcolm Wallace wrote:

...

Ross Paterson writes:

...
...
* I think that Hugs should finally be moved to darcs instead of CVS

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

This is just a matter of which options you give to 'tailor', the conversion utility. In particular, you can tell it to use the first line of the CVS commit message as the name of the darcs patch, with the remaining lines from CVS as the "long" message in darcs.

It would be very nice if you could do that conversion for the Hugs repository. I think that http://darcs.haskell.org/hugs98 will be the right place. The only thing is: Is "98" a good suffix when we will move to Haskell'? Hmmm... Anyway, having a darcs repository soon would be great.

...

The main non-automated issue when converting is the need to create/steal a darcs-all script, and maybe a utility to fix executable permissions for fresh checkouts.

I can do this after the conversion. Furthermore, I think that we can (and should) have a unified version of these scripts for GHC, Hugs and nhc98. Cheers, S.

Malcolm Wallace

4:48 p.m.

Sven Panne wrote:

...

...
This is just a matter of which options you give to 'tailor', the conversion utility.

It would be very nice if you could do that conversion for the Hugs repository.

I have been trying all day today to persuade either tailor or cvs2darcs to do the conversion, and failed miserably. I believe there is some kind of character-encoding problem causing tailor to misinterpret the contents of the CVS repo, leading to only 16 patches of history, instead of 2393. Meanwhile cvs2darcs gives me a completely empty darcs repo (after a very long time, and lots of warning messages). Does the Hugs CVS repo contain any strange encoding in commit messages? Neither ASCII nor UTF-8 seems to be accepted, whereas Latin-1 is accepted but gives incorrect results. Regards, Malcolm

Sven Panne

6:33 p.m.

On Thursday 15 March 2007 17:48, Malcolm Wallace wrote:

...

I have been trying all day today to persuade either tailor or cvs2darcs to do the conversion, and failed miserably. I believe there is some kind of character-encoding problem causing tailor to misinterpret the contents of the CVS repo, leading to only 16 patches of history, instead of 2393. Meanwhile cvs2darcs gives me a completely empty darcs repo (after a very long time, and lots of warning messages).

Does the Hugs CVS repo contain any strange encoding in commit messages? Neither ASCII nor UTF-8 seems to be accepted, whereas Latin-1 is accepted but gives incorrect results.

Do you have a log of what you did in detail? I don't have a black belt in using tailor or cvs2darcs, but perhaps I have some time in the next few days to play around a bit... Cheers, S.

Sven Panne

23 Mar 23 Mar

3:28 p.m.

On Thursday 15 March 2007 17:48, Malcolm Wallace wrote:

...

I have been trying all day today to persuade either tailor or cvs2darcs to do the conversion, and failed miserably. I believe there is some kind of character-encoding problem causing tailor to misinterpret the contents of the CVS repo, leading to only 16 patches of history, instead of 2393. Meanwhile cvs2darcs gives me a completely empty darcs repo (after a very long time, and lots of warning messages).

FYI: After patching tailor itself to make it run at all, I get 18 patches. :-( The patch was very trivial and has nothing to do with our problems, I guess: --- /home/panne/tailor/vcpx/repository/darcs/__init__.py.~1~ 2007-03-23 14:19:01.000000000 +0100 +++ /home/panne/tailor/vcpx/repository/darcs/__init__.py 2007-03-23 15:01:14.000000000 +0100 @@ -72,7 +72,7 @@ ignored.append('^%s$' % re.escape(sfrelname+'.old')) ignored.append('^%s$' % re.escape(sfrelname+'.journal')) - boring = open(boringname, 'wU') + boring = open(boringname, 'w') boring.write('\n'.join(ignored)) boring.write('\n') boring.close() -----------------------------------------------------------------------------

...

Does the Hugs CVS repo contain any strange encoding in commit messages? Neither ASCII nor UTF-8 seems to be accepted, whereas Latin-1 is accepted but gives incorrect results.

Hmmm, I can only see a single German umlaut coded in Latin-1... Cheers, S.

Sven Panne

4:03 p.m.

Further investigation show that the problematic commit is probably: date: 2006-08-10 19:31:47 +0200; author: ross; state: Exp; split off generation of the compatibility libraries into tools/make_oldlib If I see this correctly, tools/make_oldlib was introduced then, and removed a few months later: date: 2006-11-24 14:12:16 +0100; author: ross; state: dead; lines: +0 -0; remove unused script I am not sure why this should be a problem, but playing around with tailor's start-revision strongly suggests this. A bit clueless, S.

Malcolm Wallace

4:16 p.m.

Sven Panne wrote:

...

Further investigation show that the problematic commit is probably:

date: 2006-08-10 19:31:47 +0200; author: ross; state: Exp; split off generation of the compatibility libraries into tools/make_oldlib

If I see this correctly, tools/make_oldlib was introduced then, and removed a few months later:

date: 2006-11-24 14:12:16 +0100; author: ross; state: dead; lines: +0 -0; remove unused script

I am not sure why this should be a problem, but playing around with tailor's start-revision strongly suggests this.

Hmm, when I 'CVS update' to any date between those two commits, my repo does not contain tools/make_oldlib! Perhaps the CVS Attic has been disturbed, such that the file no longer exists in any revision? That might certainly confuse tailor. Regards, Malcolm

Sven Panne

4:29 p.m.

Hmmm, if I see things correctly, tailor has problems whenever it encouters a CVS file in "state: dead", i.e. when a file was removed in its past. If the CVS repo contains such a file, one gets only those changesets which are younger than that removal. I've played around a bit with a local copy of the hugs98 repo, and whenever I've removed such file from the repo itself, tailor stopped at the next dead file, and so on, and so on... Is there a trick I'm not aware of? Having dead (and perhaps resurrected) files in a CVS repo is not *that* uncommon. :-( Cheers, S.

Sven Panne

5:21 p.m.

Short note: The bleeding edge version of tailor seems to be broken. I'm currently testing the latest released version (tailor-0.9.19), and it seems to work much better, at least it's working for some time now on the hugs98 repo. But it's still in the last millenium, so I think it's time for dinner... :-) Cheers, S.

Sven Panne

24 Mar 24 Mar

2:13 p.m.

Perhaps this is the happy end of a looong story... :-) After lots of failures I think I've successfully converted the hugs repo to darcs, using tailor-0.9.26 and the attached configuration file. The new repo URL is (not surprisingly) http://darcs.haskell.org/hugs98, and it can be browsed via darcsweb, too: http://darcs.haskell.org/darcsweb/darcsweb.cgi. (The latter URL is a bit ugly, see http://www.w3.org/Provider/Style/URI. Something like http://darcs.haskell.org/darcsweb would be much better, but I don't have the permissions to fix the apache2.conf. Who can change this?) Some notes from the trenches: * In general, tailor seems to be a cool piece of SW, but given all the problems I had, I would label it "beta", still. * The bleeding edge version of tailor from darcs is completely broken regarding files which have been removed at some point in the past, one simply gets incomplete changesets, but no warnings/errors/... * The bleeding edge version even has to be modified to run at all with newer python versions (the 'U' modifier when opening files for writing is forbidden). * The latest released version I could find (0.9.27) is incompatible with the python installed on darcs.haskell.org (some 'sort' API change, I guess). * Version 0.9.19 fails to handle the conversion Latin1 => UTF8. * Version 0.9.26 seems to work, at least I hope so. Please give the new repo a try, and if everything seems to be OK, we should somehow disable the CVS repo to avoid confusion. A darcs-all script is on the way (in the next few days). Cheers, S.

Ross Paterson

4:08 p.m.

On Sat, Mar 24, 2007 at 03:13:37PM +0100, Sven Panne wrote:

...

Please give the new repo a try, and if everything seems to be OK, we should somehow disable the CVS repo to avoid confusion. A darcs-all script is on the way (in the next few days).

Looks good to me. Just a few old directories not removed: dotnet/lib/System lib libraries/Hugs If you can do something about those, let's switch.

Sven Panne

5:11 p.m.

On Saturday 24 March 2007 17:08, Ross Paterson wrote:

...

Looks good to me. Just a few old directories not removed:

dotnet/lib/System lib libraries/Hugs

If you can do something about those, let's switch.

This is funny: When I do a 'darcs get' for the repo, my local copy has those 3 empty directories, but the directories on the server are non-empty... Confused, S.

Sven Panne

5:20 p.m.

FYI: I'll re-run the conversion and test what's going regarding the empty directories. :-( Currently I'm a bit clueless because the master repo differs from the one I've checked out. I think I'll have to remove these on the server and record this change there. I'll let you know when I'm finished... *sigh* Cheers, S.

Sven Panne

25 Mar 25 Mar

3:12 p.m.

OK, let's try the next iteration... :-) I've re-converted the repo from scratch, tagged it (including a checkpoint), removed the empty directories, and finally removed the CVS keywords. Things look OK to me now, and http://darcs.haskell.org/darcsweb/darcsweb.cgi?r=hugs98;a=summary is OK, too, I think. Before we turn off Hugs' CVS, I'll have to adapt the build system, add a darcs-all, test building an RPM, etc. Nevertheless, if someone spots a flaw in the conversion up to now, please yell. Small note: tailor seems to use "darcs remove" when a file is removed from CVS, but this does not remove the file itself. Therefore the "empty" diretories stay populated, although their contents are not versioned anymore. I don't know if this is a bug in tailor or supposed to work that way. Anyway, it's a bit surprising to the unsuspecting user... Cheers, S.

Ross Paterson

4:37 p.m.

On Sun, Mar 25, 2007 at 05:12:26PM +0200, Sven Panne wrote:

...

OK, let's try the next iteration... :-) I've re-converted the repo from scratch, tagged it (including a checkpoint), removed the empty directories, and finally removed the CVS keywords. Things look OK to me now, and

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

is OK, too, I think. Before we turn off Hugs' CVS, I'll have to adapt the build system, add a darcs-all, test building an RPM, etc. Nevertheless, if someone spots a flaw in the conversion up to now, please yell.

It looks good to me too. I'm in favour of a quick switch.

Sven Panne

4:46 p.m.

On Sunday 25 March 2007 18:37, Ross Paterson wrote:

...

It looks good to me too. I'm in favour of a quick switch.

I am not sure when I can add the final touch (darcs-all etc.), but it should be in the next few days. Perhaps we should make the CVS repo read-only already and update the web pages? Cheers, S.

Ross Paterson

5:06 p.m.

On Sun, Mar 25, 2007 at 06:46:16PM +0200, Sven Panne wrote:

...

I am not sure when I can add the final touch (darcs-all etc.), but it should be in the next few days. Perhaps we should make the CVS repo read-only already and update the web pages?

Yes, let's. We'll need darcs-all for building tarballs and RPMs, but the repository is usable now. I'll do the Wiki and web pages.

Sven Panne

25 Feb 25 Feb

5:19 p.m.

On Sunday 25 February 2007 17:48, Ross Paterson wrote:

...

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.

Hmmm, so what is your exact suggestion for our numbering scheme for released versions and snapshot versions?

...

[...] 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.

Using released packages only for Hugs releases is a good thing, although GHC and nhc98 are not doing it currently (at least not via their scripts, I suspect that there is some manual intervention). I am not exactly sure how to handle this: Should we have a table of explicit package versions to get, or is there some canonical URL for the latest released version of a package? And how exactly should the sharing work? And what about nhc98?

...

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

Exactly this "bit of extra effort" is unclear to me, so I'd prefer if somebody else would do the conversion. Cheers, S.

Ross Paterson

26 Feb 26 Feb

9:52 a.m.

On Sun, Feb 25, 2007 at 06:19:55PM +0100, Sven Panne wrote:

...

On Sunday 25 February 2007 17:48, Ross Paterson wrote:

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

Hmmm, so what is your exact suggestion for our numbering scheme for released versions and snapshot versions?

YYYYMM and YYYYMM.DD?

...

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

Using released packages only for Hugs releases is a good thing, although GHC and nhc98 are not doing it currently (at least not via their scripts, I suspect that there is some manual intervention). I am not exactly sure how to handle this: Should we have a table of explicit package versions to get, or is there some canonical URL for the latest released version of a package?

For releases, we'd want a table of versions; we'd also want that in the release notes.

Sven Panne

11:46 a.m.

On Monday 26 February 2007 10:52, Ross Paterson wrote:

...

On Sun, Feb 25, 2007 at 06:19:55PM +0100, Sven Panne wrote:

...
Hmmm, so what is your exact suggestion for our numbering scheme for released versions and snapshot versions?

YYYYMM and YYYYMM.DD?

Fine with me. The date should probably be the build date in a first step. GHC'S build system is currently trying to be clever by asking darcs about the latest change and using that date, but this a bit of a hack at the moment and doesn't e.g. take into account the packages IIRC.

...

...
Using released packages only for Hugs releases is a good thing, although GHC and nhc98 are not doing it currently (at least not via their scripts, I suspect that there is some manual intervention). I am not exactly sure how to handle this: Should we have a table of explicit package versions to get, or is there some canonical URL for the latest released version of a package?

For releases, we'd want a table of versions; we'd also want that in the release notes.

I think a file containing lines like core base ??? core Cabal ??? extra OpenGL ??? extra http://www.cs.york.ac.uk/fp/darcs/polyparse ??? ... might do the trick, with the first column describing the status of the package and the second column the place to get the bleeding edge version of it (non-http: repositories can be calculated via the repository for hugs itself, see the darcs-all script for GHC, nhc98 lacks this feature). The tricky part is the third column, describing the released version to use for release builds. I guess we should use hackage somehow, but currently I fail to see how... :-( Any suggestions? Cheers, S.

Ross Paterson

12:18 p.m.

On Mon, Feb 26, 2007 at 12:46:21PM +0100, Sven Panne wrote:

...

I think a file containing lines like

core base ??? core Cabal ??? extra OpenGL ??? extra http://www.cs.york.ac.uk/fp/darcs/polyparse ??? ...

might do the trick, with the first column describing the status of the package and the second column the place to get the bleeding edge version of it (non-http: repositories can be calculated via the repository for hugs itself, see the darcs-all script for GHC, nhc98 lacks this feature). The tricky part is the third column, describing the released version to use for release builds. I guess we should use hackage somehow, but currently I fail to see how... :-( Any suggestions?

Package name+version determines the URL of the tarball stored in HackageDB, e.g. http://hackage.haskell.org/packages/archive/OpenGL/OpenGL-2.1.tar.gz and we can just assume that all packages of interest are there.

Sven Panne

12:51 p.m.

On Monday 26 February 2007 13:18, Ross Paterson wrote:

...

Package name+version determines the URL of the tarball stored in HackageDB, e.g. http://hackage.haskell.org/packages/archive/OpenGL/OpenGL-2.1.tar.gz

and we can just assume that all packages of interest are there.

Can one safely assume that http://hackage.haskell.org/packages/archive/PACK/PACK-VER.tar.gz untars into a PACK-VER directory containing that package? I hope that this is the case. So our package description file can look like this: core base 2.1 core haskell98 1.0 extra http://www.cs.york.ac.uk/fp/darcs/polyparse ftp://ftp.cs.york.ac.uk/pub/haskell/polyparse/polyparse-1.0.tar.gz extra OpenGL 2.1 ... Earlier you've mentioned some sharing of libraries. Could you elaborate a bit how this should work in detail? I only have a very vague idea, and I am not sure if this is a must or only a nice-to-have. Cheers, S.

Ross Paterson

1:25 p.m.

On Mon, Feb 26, 2007 at 01:51:42PM +0100, Sven Panne wrote:

...

On Monday 26 February 2007 13:18, Ross Paterson wrote:

...
Package name+version determines the URL of the tarball stored in HackageDB, e.g. http://hackage.haskell.org/packages/archive/OpenGL/OpenGL-2.1.tar.gz

and we can just assume that all packages of interest are there.

Can one safely assume that

http://hackage.haskell.org/packages/archive/PACK/PACK-VER.tar.gz

untars into a PACK-VER directory containing that package?

Yes, and that it contains PACK-VER/PACK.cabal. That's what "setup sdist" makes, and it is checked on upload.

...

Earlier you've mentioned some sharing of libraries. Could you elaborate a bit how this should work in detail? I only have a very vague idea, and I am not sure if this is a must or only a nice-to-have.

I'd find having copies of the source trees a bit awkward, so I use a custom setup with shadow build trees. Since GHC wants to manage the darcs trees, I link to those. Maybe it's just a nice-to-have, and things may change when GHC becomes more independent of most of the libraries.

6684

Age (days ago)

6712

Last active (days ago)

List overview

Download

26 comments

4 participants

participants (4)

Malcolm Wallace
Neil Mitchell
Ross Paterson
Sven Panne

Hugs' build system

tags

participants (4)