Library Infrastructure code & help wanted

[Isaac Jones]

"Simon Marlow" <simonmar at microsoft.com> writes:

[snip a lot]

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

Yep.

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

Yep.

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

One use I thought of for the mid-level API is something to buid the
module dependencies from the source code.  This could definitely be
reused by a wide variety of tools, including an hmake-type tool, a
ctags-type tool, etc.  That may be the only thing I've come up with,
though.

> Also, I really think we should clarify the situation as regards multiple
> Haskell implementations, which seems to be glossed over at the moment.

Yes, you've given me a lot to think about there...

> 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 don't think that's so bad.  Figuring out if a package database
already exists should be a matter of having an agreed upon
System.Directory.systemConfigDir.  Then maybe the package database
itself can tell you where to find haskell-config.

I think that the compilers / interpreters installed on the system will
also be stored in the "package config" database.  If you're
deinstalling yourself, the package database can tell you whether
you're the only compiler left and thus whether to get rid of
haskell-config.

That said, I think there are still issues with having a single package
database, for instance, what if a package configuration for one
Haskell Implementation has a field that conflicts with the package
configuration for another implementation.  Yuck!  But maybe that won't
come up.  For instance, right now there are separate flags for ghc,
nhc, and hugs opts, and probably there should be flags for shared opts.

> 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 think this would dash my hopes of being able to install a package
with a single command.  The idea so far has been to have some kind of
haskell-interactive / runhugs-type executable /usr/bin/haskell which
will execute the setup script to install and configure the package
based on the already-installed compilers.

Likewise, when you install a new compiler, it knows about what
packages are there already for the other ones and might take a crack
at building them for itself.

This isn't so far fetched: elisp for emacs and xemacs already do
something similar on Debian at least.

peace,

Isaac, who is still thinking about it