April 2008 - cabal-devel

patch applied (cabal): Fix fix for #224.
by Duncan Coutts 27 Apr '08

27 Apr '08

Sat Apr 26 09:45:37 PDT 2008 Thomas Schilling <nominolo(a)gmail.com> * Fix fix for #224. Changing from list of Dependencies to Maps resulted in the wrong Monoid instance being used. I'd still like to be able to run a test suite on this but that'd require a lot more work to do properly... M ./Distribution/PackageDescription/Configuration.hs -10 +22 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080426164537-75a80-fd3516fa…

1 0

darcs patch: Fix fix for #224.
by Thomas Schilling 26 Apr '08

26 Apr '08

Sat Apr 26 18:45:37 CEST 2008 Thomas Schilling <nominolo(a)gmail.com> * Fix fix for #224. Changing from list of Dependencies to Maps resulted in the wrong Monoid instance being used. I'd still like to be able to run a test suite on this but that'd require a lot more work to do properly...

1 0

Licence: ../LICENCE
by Peter Gammie 25 Apr '08

25 Apr '08

Does this work? On install, I think Cabal copies it to the parent of the correct directory. I use this short hand so I don't have 10 BSD3's lying around. cheers peter

2 3

patch applied (cabal-install): Rearange install plan checking code
by Duncan Coutts 24 Apr '08

24 Apr '08

Thu Apr 24 15:41:59 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Rearange install plan checking code Make it usable for callers that want to check properties before constructing an InstallPlan. M ./Hackage/InstallPlan.hs -51 +52 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080424224159-adfee-…

1 0

Re: [Hackage] #91: Building executables that use Template Haskell for profiling
by Hackage 24 Apr '08

24 Apr '08

#91: Building executables that use Template Haskell for profiling ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.6 Component: Cabal library | Version: 1.1.4 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.5 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * milestone: => Cabal-1.6 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/91#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #137: setup sdist places implementation-dependent preprocessor output in the source bundle
by Hackage 24 Apr '08

24 Apr '08

#137: setup sdist places implementation-dependent preprocessor output in the source bundle ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.6 Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------------+----------------------------------------- Changes (by duncan): * milestone: => Cabal-1.6 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/137#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

dependence analysis prototype and ideas
by Paolino 24 Apr '08

24 Apr '08

I've written some buggy code to solve the main issues which is maintained at http://catenova.org/~paolino/MakeMachine The code still doesn't include the libmachine extension as I try to explain in the document. The ideas justifying the code are readable here http://docs.google.com/View?docID=dd73w3sk_5hbwm4ffk&revision=_latest&hgd=1 Anything about that is very appreciated . Thanks Paolino

1 0

patch applied (cabal-branches/cabal-1.4): When multiple specifying list fields in the same section combine them
by Duncan Coutts 23 Apr '08

23 Apr '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.4/_darcs/patches/2008042320…

1 0

patch applied (cabal-branches/cabal-1.4): Normalise file names in warning messages
by Duncan Coutts 23 Apr '08

23 Apr '08

Wed Apr 23 12:04:57 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Normalise file names in warning messages We already do this for error messages. M ./Distribution/ParseUtils.hs -2 +3 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008042319…

1 0

patch applied (cabal-branches/cabal-1.4): Fix the check for -XFooBar ghc-options flags to be more permissive
by Duncan Coutts 23 Apr '08

23 Apr '08

Wed Apr 23 12:02:43 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix the check for -XFooBar ghc-options flags to be more permissive Previously we rejected all such flags but that posed the problem that older versions of Cabal, like 1.1.6 did not understand new extensions so we could not actually follow the advice and use the extenion. So now we only warn about -X flags if they refer to old extensions that Cabal 1.1.6 knew about. If the .cabal file specifies cabal-version: >= 1.2 or similar (anything that excludes 1.1.6) then we warn about all -X flags. M ./Distribution/PackageDescription/Check.hs -2 +24 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008042319…

1 0