Haskell library infrastructure coordinator

Peter Simons simons@cryp.to
10 Jun 2003 12:22:52 +0200

Isaac Jones writes:

 > This is the beauty of a layered tools approach like the one I
 > describe. [...] there's a lot of work to be done in both on the
 > distribution end and on the "building" end.

I guess I have to apologize. I didn't realize you intend to separate
the two stages so clearly, until now. :-(

In that case, forget everything I even argued about. I'm completely
with you.

 > Do you mind helping to convert the build system for the libraries
 > you put together once the "building" side is ready?

Not at all ... Like you suggested, my next step will be to come up
with a description of "my" project's goal, a repository layout, and a
prototype build system. This document can then be discussed, revised,
thrown away, and be re-written. :-)

 >   - Meta information that the libraries should provide (you probably
 >   don't have to or want to worry about this yet) will be important to
 >   methods of download / depends / install

I am very fond XML for this purpose, because it is so re-usable (and
can be verified for correctness). If we'd store this meta information
in a simple document, for which we provide a DTD, then I don't see a
reason why this information couldn't be re-used by a build
infrastructure wherever possible. In this case, there would be no
overlap between the two efforts at all.

Of course the same can be achieved with any format, admittedly, but
for XML there might be really good editors available, like psgml for
Emacs, etc.

 >   - If not a standard make system, at least a standard method for
 >   invoking the make system ala distutils and Debian.  You probably
 >   don't want to worry about this yet either, but keep it in mind.

In fact, I favor an Autoconf- and Make-based system over all
alternatives, just because everybody knows how to use those tools.
That's a huge advantage for the users and for the developers as well.
If there is a "better" solution, I'd like it to be able to generate
Makefiles and configure scripts, as a fallback. :-)

 >   - collect the libraries that are already included with various
 >   compilers and see what the differences are both in what libraries
 >   are included and behaviors of the libraries

 >   - find orphaned libraries (ala Numeric Quest) and try to find the
 >   authors to give them licenses.

If anybody is aware of candidate libraries, please let me know --
preferably including an URL. :-)

Also, it would help immensely if everybody would look through his
source codes and just make useful modules available for release. Then
we'd have more original material, too. I'm sure that licensing will
not be a show-stopper issue.


P. S.: Sorry for the long delay in answering your e-mail, Isaac. For
various reasons, I had to re-install my work station from the scratch
lately, and it will still take a while until I'm fully operational