- cabal-devel - Haskell.org

patch applied (cabal-install): "Fix bug where contraints where lost for case insensitive package matches" and 1 others
by Duncan Coutts 09 May '11

09 May '11

Tue May 3 07:49:32 PDT 2011 Duncan Coutts <duncan(a)community.haskell.org> * Fix bug where contraints where lost for case insensitive package matches E.g. cabal install cabal-1.8.0.6 would actually install the latest version instead, because when 'cabal' got corrected to 'Cabal' the associated constraint 'cabal == 1.8.0.6' was not converted to 'Cabal == 1.8.0.6'. M ./Distribution/Client/Targets.hs -1 +10 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-install;a=darcs_commi… Sat Apr 30 04:17:30 PDT 2011 Ben Millwood <haskell(a)benmachine.co.uk> * Correct spelling surpress -> suppress M ./Distribution/Client/Targets.hs -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-install;a=darcs_commi…

1 0

patch applied (cabal): "Implement Setup sdist --output-directory=dir"
by Duncan Coutts 08 May '11

08 May '11

Thu Apr 14 21:04:14 PDT 2011 Duncan Coutts <duncan(a)community.haskell.org> * Implement Setup sdist --output-directory=dir That is, allow generating a dir tree rather than a tarball. Apart from being useful directly, this is the right approach for tools like cabal-install. cabal-install does the tar step itself and might like to do other things like zip format. Also cleaned up the sdist code a little. M ./Distribution/Simple/Setup.hs +9 M ./Distribution/Simple/SrcDist.hs -35 +45 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

darcs patch: Correct spelling surpress -> suppress
by Ben Millwood 30 Apr '11

30 Apr '11

1 patch for repository http://darcs.haskell.org/cabal-install: Sat Apr 30 12:17:30 BST 2011 Ben Millwood <haskell(a)benmachine.co.uk> * Correct spelling surpress -> suppress

1 0

patch applied (cabal): "Add a type signature for getPrefixDirRel on Windows"
by Ian Lynagh 27 Apr '11

27 Apr '11

Wed Apr 27 07:58:35 PDT 2011 Ian Lynagh <igloo(a)earth.li> * Add a type signature for getPrefixDirRel on Windows M ./Distribution/Simple/Build/PathsModule.hs +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): "Tell hsc2hs where to find cabal_macros.h"
by Ian Lynagh 26 Apr '11

26 Apr '11

Tue Apr 26 14:05:49 PDT 2011 Ian Lynagh <igloo(a)earth.li> * Tell hsc2hs where to find cabal_macros.h M ./Distribution/Simple/PreProcess.hs -1 +3 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

[Hackage] #835: Haddocks not being built
by Hackage 26 Apr '11

26 Apr '11

#835: Haddocks not being built --------------------------------+------------------------------------------- Reporter: AntoineLatter | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- Not sure if a ticket is the right avenue. Haddocks aren't getting built on the Hackage website. http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/15681 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/835> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #837: Compile the same package with respect to several sets of flag states
by Hackage 24 Apr '11

24 Apr '11

#837: Compile the same package with respect to several sets of flag states ----------------------------+----------------------------------------------- Reporter: lemming | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.1.0 Severity: major | Keywords: Difficulty: unknown | Ghcversion: 6.12.3 Platform: | ----------------------------+----------------------------------------------- Currently I have configured my cabal with --enable-library-profiling, --enable-shared, what leads to problems with the GHC-7.0.* archives that do not contain shared objects for profiling. Actually, I do not need them, but I cannot tell Cabal to omit shared objects for profiling. If I use --enable-library-profiling and --enable-shared, then all combinations of {static, dynamic} x {non-profiling, profiling} are generated. Instead of enabling two variants by each of those 'enable' options and then generating code for all possible combinations, I would find it more useful to define sets of flags and compile modules with respect to all of these flag sets. E.g. I could write something like the following to ~/.cabal/config: {{{ flagset: dyn shared: True optimization: True flagset: p shared: False profiling: True optimization: True rts-options: True flagset: dbg flags: debug optimization: True }}} For every module A this should generate A_dyn.o, A_p.o, A_dbg.o. I do not know whether this problem can be solved in Cabal alone, or whether it also needs adaption of GHC. See also: * #600 * http://hackage.haskell.org/trac/ghc/ticket/5021 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/837> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #826: "dependency conflict"
by Hackage 24 Apr '11

24 Apr '11

#826: "dependency conflict" ---------------------------------+------------------------------------------ Reporter: nue_057 | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.3 Platform: Windows | ---------------------------------+------------------------------------------ when depnedency conflict happens, I usually use ghc-pkg unregister to solove the problem, but there is another problem. when I use ghc-pkg check, it always return a lot of problems, for example: there is a conflict with bytestring-0.9.1.10 and bytestring-0.9.1.7, I unregister the version of 0.9.1.10. ghc-pkg check, the message is: there are problems in package Win32-2.2.0.2 dependency "bytestring-0.9.1.10..." the following packages are broken, either beacause they have a problem listed above, or beacause the depend on a broken package. Win32-2.2.0.2, haskell98-1.0.1.1 QuickCheck-2.4.0.1... does anyone can help me to fix these broken package? thanks in advance !! -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/826> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #815: Feature Request: Translate buildplan to makefile
by Hackage 22 Apr '11

22 Apr '11

#815: Feature Request: Translate buildplan to makefile ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: makefile, make Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- For the following reasons, I would sometimes like to be able to use GNU make as my build system, but still get cabal's excellent dependency version calculations. Here are the main situations when I wish I had make: * Whenever I want cabal to do something that is not already common practice for cabal packages, I end up having to write a bunch of code in Setup.hs, hacking hooks, and whatnot. This always feels dirty and time consuming. * Cabal doesn't yet support parallel builds. * Cabal files that list many libraries or many executables do a lot of redundant work and the user doesn't have a fine grained way to specify which executables or libraries to build without going to a lot of extra configuration in the cabal file to add flags. * All modifications to the .cabal file require a full project rebuild, even when the changes do not impact the source or build plan. * I need to introspect the build. Perhaps it's not going as planned and I want to debug it. My only recourse at the moment is --verbose=3. I find that with the current API, using make and cabal's dependency calculations are mutually exclusive. I think the happy medium here is translating the LocalBuildInfo to a makefile (or part of a makefile). Ideally this makefile could be optionally included into another makefile. The expectation would be that the generated makefile is treated as an autogenerated file (eg., not checked into source control or statically placed on hackage). Instead it's regenerated during the configure step and then cabal or the user can invoke make to run the targets. I believe this would give us parallel builds, allow us to reuse more and recompile less, and allow us to examine the build plan. And all this would be possible by leveraging the nice statically checkable, declarative package specifications we have instead of mucking about with configure scripts or trying to write an unstructured makefile from hand and getting the rules subtly wrong. I could imagine it putting us into a harmonious state where we get the best of both worlds. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/815> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #833: Cabal mangles exceptions
by Hackage 21 Apr '11

21 Apr '11

#833: Cabal mangles exceptions ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Cabal mangles exceptions, e.g.: {{{ $ "utils/ghc-cabal/dist/build/tmp/ghc-cabal" install "/home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421/ghc" "/home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421/ghc- pkg" ":" "/home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421" libraries/ghc-prim dist-install '' '/home/ian/ghc/git/ghc/bindisttest/install dir' '/home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421' '/home/ian/ghc/git/ghc/bindisttest/install dir/share/doc/ghc/html/libraries' Installing library in /home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421/ghc-prim-0.2.0.0 ghc-cabal: /home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421/settings: openFile: does not exist (No such file or directory) }}} where a space in the filename has been replaced with a '\n'. This can be very confusing! It looks like `Distribution.Simple.Utils.topHandler` / `wrapText` is the culprit. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/833> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0