April 2008 - cabal-devel

patch applied (cabal-branches/cabal-1.4): Remove unused import
by Duncan Coutts 11 Apr '08

11 Apr '08

Wed Apr 9 00:33:52 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Remove unused import M ./Distribution/Simple/BuildPaths.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008040907…

1 0

patch applied (cabal-branches/cabal-1.4): Fix for detecting ~/.cabal/ dir as a .cabal file
by Duncan Coutts 11 Apr '08

11 Apr '08

Wed Apr 9 00:32:36 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix for detecting ~/.cabal/ dir as a .cabal file Which happened if you use cabal configure in your home dir. Now produced the right error message, or if you actually put a cabal project in your home dir, it might actually work. Also, do the same fix for findHookedPackageDesc. M ./Distribution/Simple/Utils.hs -14 +24 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008040907…

1 0

patch applied (cabal-branches/cabal-1.4): Fix spelling in error message
by Duncan Coutts 11 Apr '08

11 Apr '08

Tue Apr 8 06:46:10 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix spelling in error message M ./Distribution/PackageDescription/Check.hs -2 +2 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008040813…

1 0

patch applied (cabal): Check for the required cabal version early in parsing
by Duncan Coutts 11 Apr '08

11 Apr '08

Wed Apr 9 08:46:55 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Check for the required cabal version early in parsing Previously we only checked the "cabal-version" field after parsing and all other configure processing. If the package really needs a later Cabal version it is of course highly likely that parsing or configure are going to fail and the user is not going to get the helpful error message about the version of Cabal required. So now we do the check early during parsing. If a later version is required and parsing subsequently fails, we now report the version issue, not the subsequent parse error. If parsing succeeds we still issue a warning which should be a useful hint to the user if subsequent configure processing fails. M ./Distribution/PackageDescription/Parse.hs -15 +34 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080409154655-adfee-7618f752…

1 0

patch applied (cabal): Use relative file paths in .cabal parse error messages
by Duncan Coutts 11 Apr '08

11 Apr '08

Wed Apr 9 08:40:30 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Use relative file paths in .cabal parse error messages Do this by normalising the file path in the error message and when looking for .cabal files, by looking in '.' rather than the absolute path of the current directory. M ./Distribution/Simple/Utils.hs -6 +8 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080409154030-adfee-98e35b39…

1 0

patch applied (cabal): Remove unused import
by Duncan Coutts 11 Apr '08

11 Apr '08

Wed Apr 9 00:33:52 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Remove unused import M ./Distribution/Simple/BuildPaths.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080409073352-adfee-312cc1d2…

1 0

patch applied (cabal): Fix for detecting ~/.cabal/ dir as a .cabal file
by Duncan Coutts 11 Apr '08

11 Apr '08

Wed Apr 9 00:32:36 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix for detecting ~/.cabal/ dir as a .cabal file Which happened if you use cabal configure in your home dir. Now produced the right error message, or if you actually put a cabal project in your home dir, it might actually work. Also, do the same fix for findHookedPackageDesc. M ./Distribution/Simple/Utils.hs -14 +24 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080409073236-adfee-6bf25fc9…

1 0

patch applied (cabal): Fix spelling in error message
by Duncan Coutts 11 Apr '08

11 Apr '08

Tue Apr 8 06:46:10 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix spelling in error message M ./Distribution/PackageDescription/Check.hs -2 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080408134610-adfee-bd57c57c…

1 0

Re: [Hackage] #155: show . readPackageDescription /= id
by Hackage 11 Apr '08

11 Apr '08

#155: show . readPackageDescription /= id ----------------------------------------+----------------------------------- Reporter: kolmodin(a)dtek.chalmers.se | Owner: nominolo Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: wontfix Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux ----------------------------------------+----------------------------------- Changes (by nominolo): * status: assigned => closed * resolution: => wontfix Comment: This will never be possible in general. We can try {{{showPD . readPD . showPD . readPD == readPD}}}. Closing as wontfix. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/155#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: nice little Cabal gotcha
by Duncan Coutts 09 Apr '08

09 Apr '08

Peter, BTW, do file a bug report describing this issue so we do not forget. If you want to include my two suggestions then you could link it to the ticket aboug making cabal/cabal-install remember what files it installs. Duncan On Mon, 2008-04-07 at 18:37 +0700, Peter Gammie wrote: > Imagine this: you're hacking a library, and occasionally you put a "- > p" on your config line and sometimes you don't. > > (My cycle is occasional-clean-setup then build, which I grant might be > a bit paranoid. I get impatient and fiddle with the profiling and > optimisation options.) > > Now, if one compiles a library with "-p", then without it, the old > profiling library persists in the installed location, leading to some > head scratching when a later compilation with a "-p" config option > mysteriously fails. > > Two proposals: > > - rm -r $INSTALL_LOCATION (e.g. ~/lib/package/) > (brutal but effective; I think Cabal should claim ownership of at > least the package subdirs that it will populate) > - print "Compiling normally..." and "Compiling for profiling..." to > make it clearer when the compilation craps out > > I guess you'll be squeamish about the first one, but I for one would > like such an option when hacking. > > cheers > peter

1 0