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.