- cabal-devel - Haskell.org

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

Re: [Haskell-cafe] Hackage haddock not running?
by Antoine Latter 20 Apr '11

20 Apr '11

Maybe the cabal-devel list is also a good one to include on this? Either way I've added them to the CC list. On Wed, Apr 20, 2011 at 12:26 PM, Chris Smith <cdsmith(a)gmail.com> wrote: > I've noticed a lot of packages recently missing documentation links on > Hackage. It looks like the job to build these hasn't been running since > perhaps about Saturday. Are appropriate people aware of this? > > -- > Chris Smith > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0