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@haskell.org http://www.haskell.org/mailman/listinfo/libraries
For the end user the presence of shipment isn't important. The
shipment infrastructure should be as simple as possible and in the
best case the end user shouldn't know anything about it.
The shipment is more important for the developer. In HSQL I have to
move from one directory to another just to build the corresponding
package. The shipment as I see it is just a simple extension to Cabal.
Currently when Setup.lhs finds more than one .cabal file in the
current directory then it will raise an error. Instead I would like to
allow it to build all packages in the directory. In this case I will
be able to build all packages with one go.
I will be lucky with Simon's proposal too. It will allow to build
automatically all packages but I think that it is more complicated. At
least everything that have to be added to Cabal for this proposal will
be required in my proposal too. The aggregate package description is
in fact just a replacement for the shipment description which Isaac
proposed. I don't think that it is required to have a separate
description.
I have to write an another aggregate package. Will it be distributed
separatelly in Hackage?
Cheers,
Krasimir
2005/12/9, 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (2)
-
Krasimir Angelov -
Simon Marlow