Shipments in Cabal
simonmar at microsoft.com
Fri Dec 9 06:24:08 EST 2005
This message got garbled a bit by my mailer. It's easier to read on the
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
> 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
> the top-level package, and all the dependencies are magically
> downloaded and installed. Or they use their distro's packaging
> 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
> 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.
> 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.cabal -- build-depends: mylib, myexe1, myexe2
> myexe1.cabal -- build-depends: mylib
> myexe2.cabal -- build-depends: mylib
> 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
> 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
> - 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.
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries