Library Infrastructure code & help wanted

[Simon Marlow]

> 2) I also would like someone to help out with the package
>    configuration file IO.  Right now, it uses HaXmL, with no generated
>    code.  Someone who has seen HaXmL before could give me advice about
>    how my code could be better, submit patches, or rewrite it.  As
>    discussed on libraries at haskell.org, I'm open to not using XML if
>    someone wants to redo what I've got there (not a huge task).  This
>    parsing code is in Distribution.Package.  I do want something more
>    flexible than straight-up read/show.

I rather think that this should be considered a "sample implementation"
of the Distribution.Package API.  A consumer of the API should neither
know nor care about the on-disk representation of the package database.

I think we should specify the form of the library meta-data, at least
for the default build system (by meta-data I mean the form of toolInfo
in the example in sec. 3.4 of the doc).

We can take the approach that we specify a very simple form, which works
for most straightforward Haskell-only libraries, or we could define a
rich form which will provide enough for all but the most complex library
packages.  I think we should start with the simple form - complex
libraries will probably continue to use their own build systems for a
while yet.

The idea, as I understand it, is that we're going to provide two main
APIs:

 (b) The high-level API (Distribution.Core in the example).  Used
     by simple Setup.lhs scripts to provide generic build, install,
     and package registration services.  Consumes Distribution.Package
     internally.

 (a) The low-level API (Distribution.Package).  This is for
     custom build-systems which provide their own build & install,
     so that they can register a package.  Also used by the
     command-line tool (haskell-config?).

There may also be a mid-level API (Distribution.Build,
Distribution.Install), but I'm not sure I can see a clear use for that
at the moment.  If not, then we don't need to specify these APIs, and
they can be internal to the default build system.

Also, I really think we should clarify the situation as regards multiple
Haskell implementations, which seems to be glossed over at the moment.
Having a single package database for all Haskell implementations seems a
hard thing to implement: when GHC is installed, it will have to check
whether the database and haskell-config already exist, and similarly for
the other Haskell implementations.  When a Haskell system is
deinstalled, it has to decide whether to de-isntall haskell-config and
the package database.  

I'd rather just admit that the Haskell systems are separate, and each
provides its own implementation of Distribution.Package.  Yes, this
means that if you run Setup.lhs with Hugs it is different than running
it with GHCi:  if I want to install a package for GHC I have to run the
Setup.lhs script using GHC.  I believe that's the right way to go, and
it's much easier from our point of view: all we have to do is agree on
the Distribution.* APIs, we don't have to have any clever
install/deinstall magic to deal with shared components.

Cheers,
	Simon