Name: cabal-sort
Version: 0.0.4.1
License: BSD3
License-File: LICENSE
Author: Henning Thielemann
Maintainer: Henning Thielemann
-- Homepage: http://www.haskell.org/haskellwiki/Cabal
Category: Distribution
Synopsis: Topologically sort cabal packages
Description:
If you have a bunch of packages you may want to compile or recompile,
then you need an order of compilation that meets the dependencies.
Given a number of cabal package files,
this program reads all those files
and emits them topologically sorted according to their dependencies.
This way you can compile many packages at once,
say if a very low-level package has changed.
.
For compiling a couple of packages from their local darcs repositories
in the right order, you may run something like
.
> for dir in `find . -name "*.cabal" | fgrep -v _darcs | xargs cabal-sort --info=dir`; do (cd $dir && cabal install); done
.
For uploading a set of packages to Hackage in the right order
you may run
.
> for dir in `find . -name "*.cabal" | fgrep -v _darcs | xargs cabal-sort --info=dir`; do (cd $dir && rm dist/*.tar.gz && cabal sdist && cabal upload dist/*.tar.gz); done
.
Sometimes you have to inspect a number of packages manually,
e.g. in order to adapt your packages to a new GHC version.
In this case I found it useful to run
.
> for dir in `find . -name "*.cabal" | fgrep -v _darcs | xargs cabal-sort --info=dir`; do (cd $dir; bash); done@.
.
This way you start a local shell for every package.
Then you can easily access commands in the shell history
that you already run for previous packages,
e.g. @editor *.cabal@.
After you finished a package,
you switch to the next package
simply by leaving the shell by calling @exit@.
.
Problem 1: Given packages A, B, C,
where C depends on B and B depends on A,
and you call
.
> cabal-sort C.cabal A.cabal
.
then the emitted order of packages may be wrong,
because cabal-sort does not get to know the dependency of C on B.
Even if the order is correct,
B.cabal is missing in the output
and thus the list of cabal files cannot immediately be used
for a sequence of cabal-install runs.
.
Problem 2: We ignore flags and merge all dependencies.
This may lead to dependency cycles that cannot occur for any flag assignment.
.
You also have options @--parallel@ and @--makefile@
that support parallel compilation.
The first option is for manual parallelization
and the second one allows you to compile parallelly using
@make@'s @-j@/@--jobs@ option.
.
There is a second program called @ghc-pkg-dep@
that finds recursively all packages that a set of packages depends on.
Duplicates are eliminated and the packages are given topologically sorted,
such that you can use this for recompilation of the packages.
The packages must already be registered with @ghc-pkg@.
.
> ghc-pkg-dep pkgA-0.1 pkgB-2.3 pkgC-0.1.2
.
On GHC versions before 7.0 ghc-pkg runs quite slowly.
In order to not get bored you may run the program with @--verbose=2@ option.
Tested-With: GHC==6.10.4, GHC==6.12.3
Cabal-Version: >=1.6
Build-Type: Simple
Source-Repository head
type: darcs
location: http://code.haskell.org/~thielema/cabal-sort/
Source-Repository this
type: darcs
location: http://code.haskell.org/~thielema/cabal-sort/
tag: 0.0.4.1
Executable cabal-sort
Build-Depends:
Cabal >=1.6 && <1.15,
fgl >=5.4.2 && <5.5,
directory >=1 && <1.2,
filepath >=1.1 && <1.4,
containers >=0.2 && <0.5,
explicit-exception >=0.1.4 && <0.2,
transformers >=0.2 && <0.3,
base >=2 && <5
GHC-Options: -Wall
Hs-source-dirs: src
Main-Is: CabalSort.hs
Executable ghc-pkg-dep
Build-Depends:
Cabal >=1.6 && <1.15,
process >=1.0 && <1.2,
containers >=0.2 && <0.5,
explicit-exception >=0.1.6 && <0.2,
utility-ht >=0.0.5 && <0.1,
transformers >=0.2 && <0.3,
bytestring >=0.9.1 && <0.10,
base >=2 && <5
GHC-Options: -Wall
Hs-source-dirs: src
Main-Is: GhcPkgDep.hs