Shipments in Cabal

[Simon Marlow]

This message got garbled a bit by my mailer.  It's easier to read on the
wiki:

http://haskell.org/hawiki/Cabal_2fAggregatePackages

Cheers,
	Simon

On 09 December 2005 11:07, Simon Marlow wrote:

> 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
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries