new Library Infrastructure spec.

[Udo Stenzel]

S. Alexander Jacobson wrote:
> How is this superior to "./configure;make;make
> install"?

The Cabal proposal is basically a standardised ghc-pkg.  It allows a
script to query installed packages and provides a regular way to
register new packages.  While autoconf will have to guess almost
anything platform specific, e.g. library pathnames, Setup.lhs just
imports a library that already knows these specifics.  (Alex: Setup.lhs
does not /contain/ knowledge about pathnames, it /imports/ said
knowledge at install time.)

Therefore, Cabal supports the scenario where Angela creates a package
(her Setup.lhs is quite simple and relieves her of the platform specific
annoyances) and Joe installs it (by calling Setup.lhs the same way he
would otherwise call configure).  

That Donald Debian is also supported is almost a side effect.  To
package a Haskell library Donald doesn't have to write Setup.lhs (Angela
already did that), he writes a control file.  But since Setup.lhs
already does the hard stuff, Donald doesn't actually write the control
file, he just uses basically the same control file for every Haskell
library.  The only feature Setup.lhs has to provide for that to work is
the ability to compile a package for some path and then install it into
another.

Support for Marcus also comes at no cost.  Marcus already has his
makefile; his Setup.lhs is trivial, as it simply shells out to make.
The advantage over make is the ability to register the installed package
with every compiler and Donald can again use his proven control file.


> The priority should be in dealing with code
> created by Angela.  She should not need Peter to
> deliver a package to PNW/Wally.

She doesn't.  Wally has (by definition) at least one Haskell
implementation.  Therefore he can call Setup.lhs and get the package
installed.  That simple case is actually served best.

But Debian users *want* the help of Donald.  Though it may be quite easy
to install a source package using Cabal, the convenience of just saying
"apt-get install some-haskell-library" cannot be topped.  Therefore
Cabal is useful even for simple packages.


Anyway, I like the current proposal.  It's quite minimalistic, it serves
a well defined purpose and has the potential to serve it well.  Cabal
shouldn't be repurposed before it even goes into production.

Btw, I'd like to see a hmake-like library in the standard libraries or
as part of Cabal.  Of course, not in version 1.0 or before.


Regards,

Udo.
-- 
While climbing with a guy who had a really old and worn-looking rope, I
asked him how often he changed it. 'Everytime it breaks' he said.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/libraries/attachments/20040614/08c4b7ea/attachment.bin