April 2008 - cabal-devel

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

20 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 20 Apr '08

20 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 20 Apr '08

20 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 20 Apr '08

20 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 20 Apr '08

20 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 20 Apr '08

20 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 20 Apr '08

20 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 20 Apr '08

20 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

patch applied (cabal-install): Update for change to finalizePackageDescription
by Duncan Coutts 20 Apr '08

20 Apr '08

Sun Apr 13 15:39:10 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Update for change to finalizePackageDescription M ./Hackage/Dependency.hs -3 +2 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080413223910-adfee-…

1 0

patch applied (cabal-install): Half-done build reporting stuff
by Duncan Coutts 20 Apr '08

20 Apr '08

Sat Apr 12 16:40:57 PDT 2008 * Half-done build reporting stuff A ./Hackage/Reporting.hs View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080412234057-da39a-…

1 0