April 2011 - cabal-devel

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

Re: [Hackage] #504: executables with a C main function
by Hackage 18 Apr '11

18 Apr '11

#504: executables with a C main function ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- Changes (by jcpetruzza): * cc: jcpetruzza@… (added) Comment: I believe the lack of this feature makes SDL-based applications currently unbuildable on OS X. On OS X, SDL.h "renames" (using a macro) the "main" function to "_SDL_main"; the latter is then called from a "main" function defined in libSDLmain.a (with which every SDL-based program has to be linked). For this to work with Haskell, the workaround suggested in the SDL package is to use a C wrapper which includes SDL.h and defines a "main" function that calls, via the FFI, the entry-point of the haskell application. Notice that the workaround suggested in the ticket description does not work in this case, since the "main" function defined in the haskell wrapper would collide with the one in libSDLmain.a when linked. Observe also, that for this feature to work in a mixed Haskell/C setting like the one described, the .c program cannot be compiled first (as I think is the case with declared c-files), since it will need to #include the stubs generated from processing FFI export declarations. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/504#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal-install): "Fix a case in the new solver pruning pass" and 1 others
by Duncan Coutts 18 Apr '11

18 Apr '11

Mon Apr 18 14:12:11 PDT 2011 Duncan Coutts <duncan(a)haskell.org> * Fix a case in the new solver pruning pass It is actually possible for pruning to eliminate required packages because it's possible for it to propagate all the way up to one of the initial targets. M ./Distribution/Client/Dependency/TopDown.hs -2 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-install;a=darcs_commi… Mon Apr 18 14:14:36 PDT 2011 Duncan Coutts <duncan(a)haskell.org> * Distinguish the various impossible errors in the solver Will make tracking down problems easier in future. M ./Distribution/Client/Dependency/TopDown.hs -10 +12 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-install;a=darcs_commi…

1 0

patch applied (cabal-branches/cabal-1.10): "Refactor to avoid problems when $HOME is not set"
by Ian Lynagh 18 Apr '11

18 Apr '11

Sun Apr 17 08:41:35 PDT 2011 Ian Lynagh <igloo(a)earth.li> * Refactor to avoid problems when $HOME is not set We now avoid calling getWindowsProgramFilesDir and getAppUserDataDirectory when we don't need to know their results. This means that a GHC build goes through when $HOME is unset (GHC trac #5047). M ./Distribution/Simple/InstallDirs.hs -13 +15 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-branches/cabal-1.10;a…

1 0