- cabal-devel - Haskell.org

darcs patch: cabal-install: fix ambiguous foldr (and 2 more)
by slyich＠gmail.com 27 Dec '11

27 Dec '11

Fix build failure against ghc-7.4.-r1 3 patches for repository http://darcs.haskell.org/cabal-branches/cabal-1.14: Tue Dec 27 20:58:36 FET 2011 Sergei Trofimovich <slyfox(a)community.haskell.org> * cabal-install: fix ambiguous foldr Tue Dec 27 20:59:59 FET 2011 Sergei Trofimovich <slyfox(a)community.haskell.org> * cabal-install: fix ambiguous foldr Tue Dec 27 21:00:26 FET 2011 Sergei Trofimovich <slyfox(a)community.haskell.org> * cabal-install: allow ghc-7.4-rc1 and Cabal-1.14 Thanks! P.S.: Repo lacks default destination email address. Worth adding.

1 0

Re: [Hackage] #170: pkg-config uses a more general version scheme
by Hackage 26 Dec '11

26 Dec '11

#170: pkg-config uses a more general version scheme ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.4 Platform: Linux | ----------------------------+----------------------------------------------- Changes (by liyang): * cc: hackage.haskell.org@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/170#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #907: New cabal-install release needed for hackage
by Hackage 23 Dec '11

23 Dec '11

#907: New cabal-install release needed for hackage --------------------------------+------------------------------------------- Reporter: LeventErkok | Owner: Type: task | Status: new Priority: normal | Milestone: HackageDB Component: hackageDB website | Version: HEAD Severity: normal | Keywords: new release Difficulty: easy (<4 hours) | Ghcversion: Platform: | --------------------------------+------------------------------------------- The bug http://hackage.haskell.org/trac/hackage/ticket/656 is impacting several packages from being correctly installed on the hackage web site. Given this bug was fixed about 5 months ago, and the last cabal-install release was about 6 months ago (Mar 9th, 2011), it sounds like a new release would help move things along. This is per the discussion here: http://www.haskell.org/pipermail/cabal- devel/2011-December/007964.html -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/907> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Fixed warning with the flag -fwarn-missing-import-lists.
by Andrés Sicard-Ramírez 23 Dec '11

23 Dec '11

Hi, Using the flag -fwarn-missing-import-lists with cabal-install the line import Data.Version (Version(..)) in the generated module Paths_xxx.hs yields a warning due to the use of the (..) form of import (see http://hackage.haskell.org/trac/ghc/ticket/4489 ). The attached patch fix this issue. Best regards, -- Andrés

1 0

cabal-install version on hackage
by Levent Erkok 22 Dec '11

22 Dec '11

Hello all, This is actually a question about hackage, but looks like there's no separate hackage mailing list. I'm suffering from the issue reported in here: http://hackage.haskell.org/trac/hackage/ticket/656. In brief, cabal had a bug that prevented it from running haddock successfully if a package contained both a library and an executable that depended on it. The good news is that the bug has been fixed, about 5 months ago in fact. Unfortunately, it looks like there hasn't been an official cabal-install release since. In any case, the version of cabal that hackage uses certainly does not have this fix included, hence packages that contain library+executable combos in the newer style fail to build on the hackage site. Is there a known workaround to this problem, short of dropping the "self" dependency in the cabal file? Would it be too much to ask if hackage can upgrade it's cabal? Would that break further things? Thanks, -Levent.

2 2

Problem with runProgram (Using a shared library for the C++ in wxhaskell)
by Dave Tapley 09 Dec '11

09 Dec '11

Hi all, I've been working on the build system for wxhaskell, and ran in to a problem using "runProgram". As an experiment I've decided to put it on hpaste instead of having the mail thread get out of hand (I'm also cross posting it to the wxhaskell list and have mentioned it in #haskell, and I want to keep all correspondence in one place). Here is a link which jumps to the line where I first describe the problem I'm having: http://hpaste.org/55027#line59 Thanks, Dave

1 1

[Hackage] #871: Library with test builds the test executable against the library's cabal_macros.h
by Hackage 08 Dec '11

08 Dec '11

#871: Library with test builds the test executable against the library's cabal_macros.h ----------------------------+----------------------------------------------- Reporter: AntoineLatter | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Things like 'VERSION_package' may not only be wrong, but may cause compile errors if the library doesn't include the package in question (but the test does). This is likely to come up in a MIN_VERSION_criterion or MIN_VERSION_HUnit case. This might only be a problem if the test executable is using the new "build against a compiled version of the library" technique - I haven't played around too much. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/871> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #903: Broken links in user guide
by Hackage 05 Dec '11

05 Dec '11

#903: Broken links in user guide ----------------------------------+----------------------------------------- Reporter: graphov | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: User guide | Version: 1.8.0.6 Severity: minor | Keywords: web user guide Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- This page contains links that give 404 Not Found: http://www.haskell.org/cabal/users-guide/ For example "Distribution.Make" link: http://www.haskell.org/cabal/libraries/Cabal/Distribution-Make.html -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/903> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #410: cabal sdist does not call the sdist build hook in custom Setup.hs
by Hackage 04 Dec '11

04 Dec '11

#410: cabal sdist does not call the sdist build hook in custom Setup.hs ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Changes (by hvr): * cc: hvr@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/410#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Virtual packages
by Edward Z. Yang 02 Dec '11

02 Dec '11

Hello folks, I was thinking a little about how build flags that modify functionality are harmful for dependency resolution (pandoc and xmobar, I'm glaring at you), but authors will still use this feature because it's a lot easier than maintaining a bunch of separate packages for each different flag. It suddenly struck me, then, that what we actually needed was a mechanism not unlike what you see in traditional package managers, where a single Cabal file can specify multiple packages. pandoc.cabal might define 'pandoc' and 'pandoc-highlighting', and pandoc-highlighting can have different build dependencies, modules, etc. Module writers still need to arrange their APIs so that the extra functionality should be separable, but I don't see this as being too much of a problem. Mix-and-matching flags can be achieved by simply picking the extra virtual models as dependencies as necessary. What do you think? Cheers, Edward

3 6