Haskell library infrastructure coordinator

Peter Simons simons@cryp.to
28 May 2003 18:09:03 +0200


Isaac Jones writes:

 > [distribution vs. infrastructure]

You are right: Apparently we were approaching the issue from different
sides. :-)

My biggest problem so far is that there are numerous one-module
libraries out there, which are very useful (DeepSeq, POpen,
Shell-Haskell, etc.) and which require no "building" or "installation"
at all. But it is very annoying to collect them and to keep the local
copies up-to-date.

Also, distributing them as part of my packages may cause license
problems, users won't benefit from possibly available newer versions
they have installed, and so on. But then I cannot distribute my
package and expect the users do download a dozen small files from all
over the Internet in order to compile it either.

Solving _this_ problem is what motivated my proposal.

Obviously, more complex libraries will occasionally require special
pre-processors or multi-staged compilation, and then the build system
issue will come back to haunt us. But this is rare; even fairly
sophisticated code like HaXml or Functional MetaPost can be compiled
with "ghc --make" or "hmake" without any problems.


 > - Despite being an open CVS tree, the approach is rather
 >   "cathedral".

I think it combines the best of both worlds: The "unstable" area
serves as the bazaar, where people can do whatever they want. Whereas
the "stable" area should provide production quality libraries. At the
very minimum, the APIs of code in there should not change from one day
to another.


 > - Some authors won't want to store a copy of their code on another
 > CVS repository if their projects already have a home. This could
 > cause redundancy and / or forking.

True. This is why I came up with cvssynch, so that the project could
import code from other repositories in a semi-automated fashion --
without forking. But ultimately, it's up to the library author.


 > I'd be interested to see how your proposal fits with mine in your
 > eyes.

>From what I understand, your idea aims for something even bigger than
mine: You'd like to have a tool infrastructure, which can retrieve,
build and install pretty much any library for you, like the "ports"
system of BSD Unix, right? I like the idea very much, and the two
approaches are not mutually exclusive at all. Such a system could, for
instance, easily fetch and build "hslibs" -- just like any other
library it supports.

So maybe we're talking about two separate but related projects,
actually?


 > Also, you mentioned hbuild, can you discuss how this improves upon
 > hmake?

HBuild is going to be a full generic "make". The only difference to
ordinary make tools is you don't write a Makefile, you write a Haskell
program using a monadic combinator library, which you compile to get a
project-specific build tool. You can think of "runhugs" to represent
"make" and the Haskell source code to represent the "Makefile", if you
want. :-)

This is really work in progress, though. I'm having a lot of trouble
coming up with a satisfactory design of the library, precisely because
building software is so messy. (I already mentioned variant builds in
an earlier post, for example.)

Anyhow, HBuild is not really essential to the idea of the hslibs
repository. (Neither is cvssynch.) It's just something I have been
experimenting with ...

Peter