- cabal-devel - Haskell.org

patch applied (cabal): fix import for nhc98
by Malcolm Wallace 22 Apr '08

22 Apr '08

Tue Apr 22 06:30:09 PDT 2008 Malcolm.Wallace(a)cs.york.ac.uk * fix import for nhc98 M ./Distribution/Simple/Setup.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080422133009-6871e-4110c628…

1 0

Cabal spelunking considered tricky
by Bryan O'Sullivan 21 Apr '08

21 Apr '08

As I've been maintaining cabal-rpm to try to keep up with developments in Cabal, I've found myself wondering why it's not using many of the usual tricks to hide the plumbing, such as a custom monad transformer stack. Some parameters, such as flags, compiler info, and package descriptions, pop up simply all over the place, and they're passed around explicitly. This seems a smidge peculiar. A couple of days with a crowbar and ReaderT StateT IO would do wonders for readability, if anyone feels so inclined :-) <b

2 2

[Hackage] #224: allow specifying package version constraints to configure
by Hackage 21 Apr '08

21 Apr '08

#224: allow specifying package version constraints to configure ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Currently, configure considers the version constraints from the `build- depends` of the `.cabal` file. Of the available packages that satisfy those constraints it picks the highest version. This is not always what we want. The user might want to pick a specific version of a dependency (eg for testing or to avoid a known dud). cabal-install certainly wants to specify package versions exactly because it does its own dependency resolution and it may well end up not picking the latest version of an available dependency, eg to ensure consistent versions of a dependent package (see #220). So the dependencies would be specified just as in `build-depends`, for example: {{{ cabal configure --constraint="bytestring == 0.9.0.1" }}} (suggestions for a better flag name welcome) However it must only be for dependencies that the package actually depends on. It should be an error to specify constraints on packages that could never be used by the package we are configuring. The fact that package dependencies can be conditional complicates this slightly. To be precise, we could say that if the package name is not mentioned in the flattened package description then it is an error. If the package named in the constraint happens merely not be use in the selected configuration then it is not an error and the constraint is discarded. So an external package manager (like cabal-install) can control exactly how a package will be configured by setting all the use flags and precisely constraining all the dependencies. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/224> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #264: unionBuildInfo should not always use nub
by Hackage 21 Apr '08

21 Apr '08

#264: unionBuildInfo should not always use nub ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The below report was originally filed as http://hackage.haskell.org/trac/ghc/ticket/2190 In libraries/Cabal/Distribution/PackageDescription.hs, the unionBuildInfo function combines, for example, ldOptions from two BuildInfos, using nub to eliminate duplicate arguments. This is wrong for ldOptions and some other elements. For example, if ldOptions contains: {{{-Xlinker -R -Xlinker /dir1 -Xlinker -R -Xlinker /dir2}}} Then the nubbed result is: {{{-Xlinker -R /dir1 /dir2}}} which doesn't work at all. There may be some redundancy that could be eliminated, but for arguments passed to external programs, it can only be done safely by understanding the semantics of the arguments. Similarly for extraLibs, {{{-lfoo -lbar -lfoo}}} may be necessary if {{{libfoo}}} and {{{libbar}}} reference each other's symbols. Using nub is wrong for at least cppOptions, ccOptions, ldOptions, and extraLibs. But I think it is necessary for some other BuildInfo components, like hsSourceDirs, so it can't be removed completely; that results in an error while building GHC: {{{ Preprocessing library unix-2.3.0.0... Generating Makefile unix-2.3.0.0... Setup: makefile: can't cope with multiple hs-source-dirs yet, sorry }}} So {{{combine}}} could take an extra arguments, which would be nub in some cases or id in others. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/264> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

patch applied (cabal-install): Update for FlagAssignment changes
by Duncan Coutts 21 Apr '08

21 Apr '08

Sun Apr 20 12:15:43 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Update for FlagAssignment changes M ./Hackage/DepGraph.hs +2 M ./Hackage/Dependency.hs -4 +4 M ./Hackage/Install.hs -3 +4 M ./Hackage/InstallPlan.hs -3 +3 M ./Hackage/Types.hs -6 +2 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080420191543-adfee-…

1 0

patch applied (cabal-install): Add new InstallPlan type
by Duncan Coutts 21 Apr '08

21 Apr '08

Mon Apr 14 10:19:14 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add new InstallPlan type This is joint work with Kolmodin. An InstallPlan records what we want to install and records the outcome of installing packages. It has a fairly strict internal invariant which should guarantee that each package can be configured sucessfully. A ./Hackage/InstallPlan.hs View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080414171914-adfee-…

1 0

patch applied (cabal-install): Simplify install --only implementation
by Duncan Coutts 21 Apr '08

21 Apr '08

Mon Apr 14 07:34:57 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Simplify install --only implementation The install --only doesn't do any planning or build reporting so make it completely separate so we do not have to make up fake build plans or results. M ./Hackage/Install.hs -17 +6 M ./Main.hs +3 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080414143457-adfee-…

1 0

patch applied (cabal-install): Change resolveDependencies to take OS and Arch as parameters
by Duncan Coutts 21 Apr '08

21 Apr '08

Sun Apr 13 17:04:19 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Change resolveDependencies to take OS and Arch as parameters Rather than using global 'constants' for the current os and arch. M ./Hackage/Dependency.hs -21 +28 M ./Hackage/Fetch.hs -2 +6 M ./Hackage/Install.hs -3 +8 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080414000419-adfee-…

1 0

patch applied (cabal-install): Make ResolvedDependency an internal detail of dependency calculation
by Duncan Coutts 21 Apr '08

21 Apr '08

Sun Apr 13 16:41:19 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Make ResolvedDependency an internal detail of dependency calculation Externally we currently use a DepGraph, though we'll move to a InstallPlan. This is a step towards making it easier to swap in different package dependency resolution algorithms. Because we're hiding ResolvedDependency we have to disable the extended Hackage.Info stuff for the moment. M ./Hackage/Dependency.hs -12 +18 M ./Hackage/Fetch.hs -3 +2 M ./Hackage/Install.hs -11 +10 M ./Hackage/Types.hs -11 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080413234119-adfee-…

1 0

patch applied (cabal-install): Relax version constraint on HTTP, seems to work with 3001.1
by Duncan Coutts 21 Apr '08

21 Apr '08

Sun Apr 13 15:39:40 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Relax version constraint on HTTP, seems to work with 3001.1 M ./cabal-install.cabal -1 +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080413223940-adfee-…

1 0