Cabal interface changes proposal

Hi Gang, 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 -= 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? -= Notes =- Copy function: I'm not crazy about the way that "install" has different behavior depending on the --install-prefix flag. In particular, without the flag, it doesn't register, with the flag, it does. This is convenient, but inconsistent. I hope that this command will clean it up. It was Ian Lynagh's idea. Postinst: This is related to the discussion about ghc-pkg on the libraries list. The idea is to have a command that's guaranteed to run on the target. This frees up the register command to be more flexible. By default, postinst will do nothing, just like "./setup test". peace, isaac

--- Isaac Jones
-= 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?
I am strongly advocating to have one to one correspondence between Cabal packages and Haskell packages. It would be even simpler if in each Cabal package we have only one library or only one executable. I like the Simon's proposal of shipments. If we need a package with one library and multiple executables we can use shipment too. Currently we have Setup.description for each package. I propose to change the name to Package.description and to introduce Shipment.description file. The latter will contain the name of shipment and the list of Package.description files in it. The Cabal package should export defaultMain and defaultShipmentMain functions, where the former builds a single package while the latter builds a shipment. Cheers, Krasimir __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
participants (2)
-
Isaac Jones
-
Krasimir Angelov