December 2008 - cabal-devel

patch applied (cabal): Add checks for file glob syntax
by Duncan Coutts 02 Dec '08

02 Dec '08

Tue Dec 2 05:39:54 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Add checks for file glob syntax It requires cabal-version: >= 1.6 to be specified M ./Distribution/PackageDescription/Check.hs -2 +33 M ./Distribution/Simple/Utils.hs +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20081202133954-adfee-acfca21b…

1 0

patch applied (cabal): Add check for use of "build-depends: foo == 1.*" syntax
by Duncan Coutts 02 Dec '08

02 Dec '08

Tue Dec 2 05:14:59 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Add check for use of "build-depends: foo == 1.*" syntax It requires Cabal-1.6 or later. M ./Distribution/PackageDescription/Check.hs -2 +66 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20081202131459-adfee-80ed2734…

1 0

patch applied (cabal): Distinguish version wild cards in the VersionRange AST
by Duncan Coutts 02 Dec '08

02 Dec '08

Fri Nov 28 09:05:13 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Distinguish version wild cards in the VersionRange AST Rather than encoding them in existing constructors. This will enable us to check that uses of the new syntax are flagged in .cabal files with cabal-version: >= 1.6 M ./Distribution/Version.hs -41 +27 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20081128170513-adfee-e303e92a…

1 0

cabal.exe does not like ghc head's array-0.2.0.0 or containers-0.2.0.0?
by Claus Reinke 02 Dec '08

02 Dec '08

With a freshly built ghc head (on windows, using cygwin bash), using the cabal.exe binary $ /cygdrive/d/archive/haskell/cabal/cabal.exe --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library I thought I'd make another attempt at bootstrapping cabal-install, but I get odd dependency resolutions, eg: $ /cygdrive/d/archive/haskell/cabal/cabal.exe install cabal-install --dry-run Resolving dependencies... In order, the following would be installed (use -v for more details): array-0.2.0.0 HTTP-3001.1.5 containers-0.2.0.0 Cabal-1.6.0.1 zlib-0.5.0.0 cabal-install-0.6.0 Note that both array and containers are already installed: $ ghc-pkg list c:/ghc/ghc-6.11.20081202\package.conf: Cabal-1.5.5, HUnit-1.2.0.3, QuickCheck-1.2.0.0, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.0, base-4.0.0.0, bytestring-0.9.1.4, containers-0.2.0.0, directory-1.0.0.2, ffi-1.0, filepath-1.1.0.1, (ghc-6.11.20081202), ghc-paths-0.1.0.5, ghc-prim-0.1.0.0, haddock-2.3.0, haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.2, html-1.0.1.2, integer-0.1.0.0, mtl-1.1.0.2, network-2.2.0.1, old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.1.0.0, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2, syb-0.1.0.0, template-haskell-2.3.0.0, time-1.1.2.2, xhtml-3000.2.0.1 Should I be worried?-) Claus

1 0

[Hackage] #421: Cabal shouldn't try to build split-objs when ghc reports it does not support it
by Hackage 01 Dec '08

01 Dec '08

#421: Cabal shouldn't try to build split-objs when ghc reports it does not support it ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: low | Milestone: Cabal-1.8 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.3 Platform: | ------------------------------+--------------------------------------------- It is possible to build ghc without support for object splitting. In such a case Cabal should refuse to work if the user enables split objs. All one has to do is to parse the output of `ghc --info` (which is in a `Read/Show` format). See also #24. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/421> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #422: Cabal should warn if using a version of ghc that is newer than Cabal knows about
by Hackage 01 Dec '08

01 Dec '08

#422: Cabal should warn if using a version of ghc that is newer than Cabal knows about ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.3 Platform: | ------------------------------+--------------------------------------------- It seems to often happen that newer versions of ghc make changes that break old versions of Cabal. This is particularly a problem for `cabal- install` since that need not necessarily be upgraded when ghc is upgraded. Probably it should warn if the major version is bigger than the known version at the time. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/422> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

darcs patch: Fix #396 and add let .Haddock find autogen modules
by Andrea Vezzosi 01 Dec '08

01 Dec '08

Mon Dec 1 12:48:53 ora solare Europa occidentale 2008 Andrea Vezzosi < sanzhiyan(a)gmail.com> * Fix #396 and add let .Haddock find autogen modules

1 1

[Hackage] #418: 'cabal check' should warn about open lower bounds
by Hackage 01 Dec '08

01 Dec '08

#418: 'cabal check' should warn about open lower bounds ---------------------------------+------------------------------------------ Reporter: Saizan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ Dependencies of the form "foo > x" don't really make sense given the hackage version policy, since they exclude x but include x.y which is supposed to have a similar api, and if you want something introduced in a minor (or lesser) release you can explicitly mention that. Also what is often intended with that notation is foo >= (x+1), causing confusion. I propose that we allow only closed lower bounds, i.e. foo >= x. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/418> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1