- cabal-devel - Haskell.org

patch applied (cabal-install): Fix bug in passing the verbosity value when re-executing cabal
by Duncan Coutts 02 Jun '08

02 Jun '08

Sun Jun 1 22:25:36 PDT 2008 Andrea Vezzosi <sanzhiyan(a)gmail.com> * Fix bug in passing the verbosity value when re-executing cabal It was passing the value as another argument, distinct from the flag. M ./Hackage/Install.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080602052536-cd449-…

1 0

darcs patch: Fix bug in passing the verbosity value when re-executi...
by Andrea Vezzosi 02 Jun '08

02 Jun '08

Mon Jun 2 07:25:36 CEST 2008 Andrea Vezzosi <sanzhiyan(a)gmail.com> * Fix bug in passing the verbosity value when re-executing cabal It was passing the value as another argument, distinct from the flag.

1 0

patch applied (cabal-install): Implement plan improvement
by Duncan Coutts 02 Jun '08

02 Jun '08

Sun Jun 1 17:00:18 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Implement plan improvement The idea is to improve the plan by swapping a configured package for an equivalent installed one. For a particular package the condition is that the package be in a configured state, that a the same version be already installed with the exact same dependencies and all the packages in the plan that it depends on are in the installed state. M ./Hackage/Dependency/TopDown.hs -9 +55 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080602000018-adfee-…

1 0

Probably Cabal bug
by Krasimir Angelov 01 Jun '08

01 Jun '08

Hi, I have a package with one library and one executable. Something like this: name: ... version: ... library build-depends: base, array, containers, bytestring, random .... executable ... build-depends: base, array, containers, bytestring, filepath, directory, random, old-time, process, pretty Although I specified that the library depends only on few packages the installed package really depends on the union of packages for listed for the library and for the executable. I am using Cabal-1.2.3.0. Is this a known issue?

2 1

patch applied (cabal-branches/cabal-1.2): Bump version number to 1.2.4.0
by Ian Lynagh 31 May '08

31 May '08

Thu May 29 10:23:38 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Bump version number to 1.2.4.0 And update the changelog. There should be no incompatible API changes or incompatible behaviour changes. There are a number of compatible API extensions and behaviour fixes. In particular this gives us a limited amount of forward compatabilty with Cabal-1.4, ie there are things that work in 1.4 that would break with 1.2.3.0 but should work with 1.2.4.0. M ./Cabal.cabal -2 +2 M ./Makefile -2 +2 M ./changelog +14 M ./releaseNotes -1 +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008052917…

1 0

patch applied (cabal-branches/cabal-1.2): Fix backport of 'Find original sources for main-is when creating sdist'
by Ian Lynagh 31 May '08

31 May '08

Thu May 29 10:07:15 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix backport of 'Find original sources for main-is when creating sdist' Required an extra util function. M ./Distribution/Simple/SrcDist.hs -2 +3 M ./Distribution/Simple/Utils.hs -7 +35 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008052917…

1 0

patch applied (cabal-branches/cabal-1.2): Find original sources for main-is when creating sdist
by Ian Lynagh 31 May '08

31 May '08

Thu Jan 31 03:49:09 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Find original sources for main-is when creating sdist Also add a package sanity check that main-is must specify a .hs or .lhs file. So the bahaviour is now that main-is specifies the main source file, even if that is generated by a pre-processor. This isn't really a change in behaviour since previously if you specified main-is: main.hsc then it would try to pass the .hsc file to ghc dirctly which would not work. For ticket #14 things were fixed to that it would look for main.hsc if you used main-is: main.hs an that file did not exist directy. This completes the other half, of actually being able to make a src distribution. So this should fix bug #217. Note that this still needs some work, we do not run platform-independent preprocessors and put the result into the tarball for main-is files. Generally, main-is has been the second class citizen compared to normal modules. We should try and refactor so both use the same code paths. M ./Distribution/PackageDescription.hs -4 +8 M ./Distribution/Simple/SrcDist.hs -1 +5 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008013111…

1 0

patch applied (cabal-branches/cabal-1.2): When multiple specifying list fields in the same section combine them
by Ian Lynagh 31 May '08

31 May '08

Wed Apr 23 13:15:19 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * When multiple specifying list fields in the same section combine them eg if you had: extensions: Foo extensions: Bar, Baz then previously we only ended up with [Bar, Baz]. Now we get them all. Only applies to list fields, for single fields the second value is taken and the first is silently discarded. This isn't good of course but the fix is harder since we're not in a context where we can report errors. Really we should just declare up front what kind of field it is and inherit the right behaviour automagically, either duplicates disallowed or allowed and combined with mappend. M ./Distribution/ParseUtils.hs -3 +7 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008042320…

1 0

patch applied (cabal-branches/cabal-1.2): We do not show the field value on a parse error so don't pretend we do.
by Ian Lynagh 31 May '08

31 May '08

Thu Mar 27 15:14:42 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * We do not show the field value on a parse error so don't pretend we do. Drop the trailing ": " on the error message. We could provide the field value but they're often multi-line and we cannot pin-point where the error is exactly. M ./Distribution/ParseUtils.hs -2 +2 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008032722…

1 0

patch applied (cabal-branches/cabal-1.2): Fix rejection of non-ambigious options
by Ian Lynagh 31 May '08

31 May '08

Sat Mar 8 04:09:02 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Fix rejection of non-ambigious options This GetOpt patch was sent the the libraries list by Eelis van der Weegen with the explanation: There is a bug in System.Console.GetOpt causing it to mistakenly reject options as ambiguous. Example: optsDesc = [Option "" ["color", "colour"] (ReqArg id "color") ""] Output: option `--col' is ambiguous; could be one of: --color=color, --colour=color Foreground color --color=color, --colour=color Foreground color This error is silly, because the two alternatives listed are the same option. M ./Distribution/GetOpt.hs -2 +3 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.2/_darcs/patches/2008030812…

1 0