Shipments in Cabal

[Simon Marlow]

I've read the thread, and I must admit I've been thinking along the same
lines as Duncan.  We don't need shipments.  The problem is purely with
developing aggregate packages, which we can solve with either tools or
small additions to Cabal.  (sorry, I intended this to be a short
message, but it's turned out rather long :-/)

I don't propose to change much, in fact I want to make the situation
simpler:

  Cabal package
	== one library or one executable
      == one distro package
      == one distributable

To aggregate packages, just create another package which contains only
dependencies.  This is how many distro packaging systems aggregate eg.
all the KDE components into a single KDE package.

1. End users: they are served by this just fine.  They just
cabal-install
   the top-level package, and all the dependencies are magically
   downloaded and installed.  Or they use their distro's packaging
system
   to do the same thing.  Dependencies between libraries are maintained
   correctly.

2. Developers.  A developer working on an aggregate package needs to be
   able to edit & rebuild an aggregate package without rebuilding
   everything every time.  This is the scenario I believe we should
solve
   with a few small additions to Cabal (see below).

3. Visual studio.  VS has solutions, which are containers for multiple
   packages, but the problem is that it doesn't want to *install* each
   package as it builds, but it somehow needs to make each package
   available to the others when building a chain of dependencies.
Again,
   this is solved by the same small additions to Cabal.


As a developer, here is how I'd like to work on an aggregate package.
Suppose I have three packages mylib, myexe1, myexe2.  I aggregate these
using a package bigpkg.  I then arrange my tree like this:

  .../bigpkg/
       Setup.lhs
       bigpkg.cabal   -- build-depends: mylib, myexe1, myexe2
       mylib/
          Setup.lhs
          mylib.cabal
          src/
       myexe1/
          Setup.lhs
          myexe1.cabal -- build-depends: mylib
          src/
       myexe2/
          Setup.lhs 
          myexe2.cabal -- build-depends: mylib
          src/

and I want to work on the whole blob like this:

  $ cd .../bigpkg
  $ runghc Setup.lhs configure --local
  $ runghc Setup.lhs build

what does --local do? (we can choose a better name, incedentally):

  - it implies 
        --local-deps
        --prefix=`pwd`/install 
        --packagedb=`pwd`/install/package.conf

what does --local-deps do?

  - "configure" looks for dependencies in subdirectories of `pwd`

  - "configure" configures recursively.  It passes
    --prefix and other settings to each subdir

  - "build" command recursively builds dependencies that
    are found in subdirectories, in dependency order.  After building
    each library dependency, it runs "setup install" in that subdir.

  - other commands just operate recursively.

what does --packagedb do?

  - specifies a package database into which packages are registered
    by "setup register" and "setup install"

  - you probably want to set GHC_PACKAGE_PATH too


-=-=- Summary -=-=-

  - Add --packagedb flag to Cabal.  This just adds a -package-conf
    to each invocation of GHC and ghc-pkg.

  - Add --local-deps flag to "setup configure" in the simple build
    sysetm, which looks for dependencies in subdirectories, and causes
    other setup commands to recurse into dependencies in the right
    order.

  - Add --local flag which is just a macro


Pretty simple to implement, and does everything we want, I think.

Visual Studio would do things slightly differently, but I believe these
facilities provide everything VS needs from Cabal.

Incedentally, I want --local for converting GHC's libraries to Cabal.
We need to build & use directly from the build tree, which is what
--local does.

Cheers,
	Simon