Library Infrastructure code & help wanted

[Simon Marlow]

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

What about multiple versions of GHC installed on a system, each with
different sets of packages installed?  Can I still install GHC in my own
home directory, without needing to modify files in /etc?

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

Also, there doesn't seem to be provision in the package configuration
for naming libraries specific to a particular implementation (eg. to use
this package on GHC you must link in libHSwibble.a from /foo/bar, but on
nhc98 you link in libHSnhc_wibble.a from ...).  It seems to me that
every field needs to be duplicated for each compiler installation;
either that or you could put the compiler name in the package
identifier, so you'd have packages like "ghc-6.2-base-1.0",
"nhc98-1.3-base-1.0".

Incedentally, GHC never uses the extra_ghc_opts in the package
configuration.  In fact, I don't think it should be there: it doesn't
make sense in conjunction with auto packages (if I don't know whether
I'm using a package or not, I don't know whether to add the flags).  The
flags fields should be disabled if auto is True.

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

It doesn't prevent you doing this.  Here's how it might work:

  - Each compiler has their own package database, and their own
    implementation of Distribution.Package with an
    implementation-defined location for the package database(s).

  - There is a suite of tools, including haskell-config and
    /usr/bin/haskell, which are installed only once.
    These tools know about all the installed compilers on the
    system.  We could install these tools with a compiler, or
    separately; installs/deinstalls of compilers need to update
    some state so that the tools are aware.

  - /usr/bin/haskell could run the script it is given using
    each compiler on the system, if that's what you want.  eg.

    $ /usr/bin/haskell script.hs
    -- runs script.hs using the default compiler

    $ /usr/bin/haskell --all script.hs
    -- runs the script using each compiler on the system

    so to do an installation for all compilers, you say
    './Setup.lhs --all --install', assuming that Setup.lhs begins with
    '!#/usr/bin/haskell'.

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

We can aim for this in the long term if you like - I still believe this
is something that the package management system should do for us,
though.  The end result is the same, and it's a lot less work.

Cheers,
	Simon