Cabal interface changes proposal

Isaac Jones ijones at
Sat Nov 20 20:15:01 EST 2004

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

By default, postinst will do nothing, just like "./setup test".



More information about the Libraries mailing list