On 21 November 2004 01:15, Isaac Jones wrote:
I would like to make a few interface changes to Cabal, but I want to get some feedback first, and to give a heads-up.
By "target" I mean "place where the package will end up getting installed" rather than the build machine, which may be different.
-= New commands =-
./setup copy (similar to ./setup install, with or without a prefix. Never runs register or postinst) ./setup test (runs a user-supplied IO () function) ./setup postinst (guaranteed to run on the target after register, runs a user-supplied IO () function)
-= Changes to existing commands =-
./setup install now will not have the --install-prefix flag. Use "copy" instead. Install will always run register and postinst.
./setup register may or may not run on the target machine
This all looks good to me.
-= Changes to package description file =-
I can imagine a cabal package (wxhaskell) which has more than one "haskell package" / library in a single source tree.
We might like to have more than one "haskell package" per "cabal package". That is, installing a single cabal package, Foo, might make "-package bar -package bang" available to the compilers.
So I propose that we add the ability to have multiple libraries, just as we can currently do multiple executables.
Right now, there's no great way to do this, besides perhaps having multiple directories with multiple Setup.lhs files. The downside to this is that it might make the description file a little more complex, though in the simple case, it won't change much. What do folks think?
First of all, I should say that I doing see an urgent need for this. Packaging systems such as Debian, *BSD & Gentoo manage dependencies and can build multiple packages in the right order just fine, and have support for "collection" packages (eg. installing "kde" causes a bunch of sub-packages to be installed). Introducing this functionality in Cabal would be redundant on these systems. My feeling has always been that we shouldn't duplicate functinoality that is available in a good package system. Given that, if you really want to do this, then here are my thoughts: basically it would mean introducing another "layer" of packaging, albeit one that lives only at the Cabal level, which Haskell compilers know nothing of. Here are some issues that initially spring to mind: - Packages in this layer should be called something other than packages, to avoid confusion (I'll call them shipments, for now). - Should the shipment have a name of its own? - Should it have a version? - Presumably the packages in a shipment depend on each other. That means we need to "temporarily" install packages so we can build against them. This isn't something that the current package proposal really supports, but I think it would be useful. Cheers, Simon