May 2010 - cabal-devel

patch applied (cabal): Fix warnings
by Ian Lynagh 09 May '10

09 May '10

Sat May 8 17:33:09 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Fix warnings M ./Distribution/Simple/Program/Builtin.hs +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

patch applied (cabal): Allow filepath-1.2.*
by Ian Lynagh 09 May '10

09 May '10

Wed May 5 03:13:13 PDT 2010 Simon Marlow <marlowsd(a)gmail.com> * Allow filepath-1.2.* M ./Cabal.cabal -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 09 May '10

09 May '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: duncan Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Changes (by juhp): * cc: petersen@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:33> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #684: Flags combined in the wrong order when nested
by Hackage 08 May '10

08 May '10

#684: Flags combined in the wrong order when nested ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.2 Severity: minor | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- One explanation of this problem is here: http://www.mail-archive.com/cabal-devel@haskell.org/msg05939.html It would appear that when some flags are specified outside of an if- statement the are combined in a different order than when they are combined inside an if-statement. I have confirmed that Brent's work around works on the darcs.cabal file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/684> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #649: better warning messages for why dependencies are missing / cannot be selected
by Hackage 07 May '10

07 May '10

#649: better warning messages for why dependencies are missing / cannot be selected ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by duncan): Similarly, for installed constraints we should explain in error messages that an installed version is required and list any installed versions that were not suitable or were otherwise excluded. Consider for example: {{{ build-depends: base == 4.1.* }}} Suppose someone runs `cabal install` on this when the only available versions of base are 3.0.3 and 4.2.0 (ie using ghc-6.12.x). Currently we will report: {{{ cabal: cannot configure foo-1.0. It requires base ==4.1.* For the dependency on base ==4.1.* there are these packages: base-4.1.0.0. However none of them are available. base-4.1.0.0 was excluded because of the top level dependency base -any }}} This lists all the non-installed versions that satisfy the version constraint and tells us (badly) that they're no good because they're not installed. Instead in this situation it's probably better to say it needs an installed version and list the (hopefully) small number of installed versions, even if they do not satisfy the version constraint. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/649#comment:1> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Missing modules
by Simon Peyton-Jones 06 May '10

06 May '10

Dear Cabal developers If you look at http://hackage.haskell.org/trac/ghc/ticket/3951 you'll see an example of a very confusing link-time error message. The ultimate cause was that a package author omitted one of the modules when listing the package manifest (in exposed and hidden modules). But there is no error when building the package -- the error only shows up when linking a complete application that uses the package. This is obviously bad. When Cabal builds the package, we should clearly check that no modules are omitted. You probably have a ticket on this already, but I thought I'd mention it. Simon

1 0

[Hackage] #683: cabal-install init should ask for Main-is for executables
by Hackage 05 May '10

05 May '10

#683: cabal-install init should ask for Main-is for executables ---------------------------------+------------------------------------------ Reporter: ezyang | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Main-is is a required field for executable sections, so cabal-install should ask for it. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/683> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #680: Spec should define the interpretation of the library and includes and search dirs
by Hackage 05 May '10

05 May '10

#680: Spec should define the interpretation of the library and includes and search dirs ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal specification | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------------+----------------------------------------- See http://hackage.haskell.org/trac/ghc/ticket/3930 The Cabal spec should say how to interpret the `extra-libraries` and `library-dirs` fields in the installed package info. Specifically how this information is interpreted in relation to package dependencies which may also specify libraries and search paths. The interpretation should be that all the `extra-libraries` required by a installed package should be found in `library-dirs` given in that installed package info, or in the "standard" system linker path (as used by the standard system linker). That is, the `library-dirs` of dependent packages should not be used. For example: {{{ -- installed package gtk: extra-libraries: gtk-x11-2.0 library-dirs: depends: glib -- installed package glib: extra-libraries: glib-2.0 library-dirs: /opt/local/lib }}} We presume here that `/opt/local/lib` is not on the standard linker path. Then we should only look for the `gtk-x11-2.0` library on the paths specified in the gtk package, which in this case is empty, so that means only on the system linker path. If `gtk-x11-2.0` is in fact only in `/opt/local/lib` then this will and should fail. We should not use the library dirs of the `glib` package to find the libraries of the `gtk` package. The correct information for the above example would be to list `library- dirs: /opt/local/lib` for the gtk package also. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/680> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #678: Add framework to provide ad-hoc diagnostics for common failures
by Hackage 03 May '10

03 May '10

#678: Add framework to provide ad-hoc diagnostics for common failures ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Just as we have a system for doing various QA checks on cabal packages, perhaps we should have something to help users diagnose common problems with the system environment that crop up as e.g. linker errors. For example, a user reported in #haskell that the wx package failed to configure and reported that the `stdc++` C library was missing. We eventually discovered that although the standard C++ library was installed, it was not found by `gcc -lstdc++`. Installing the C++ components of gcc (ie the distro package that provides `g++`) fixed the issue, presumably because installing that package modified the standard gcc linker search path to include the location where `stdc++` was already installed. It would be good if after diagnosing this particular issue, it was easy to code up a test for this situation and add it into Cabal's `Simple` build system so that other users might get more helpful diagnostics in future. It does not need to be comprehensive, so it is ok to try and grok the output of linkers and to work just on some OSs or just with gcc for example. This might also help with common ghc problems. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/678> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #330: Support general documentation, not just haddock
by Hackage 03 May '10

03 May '10

#330: Support general documentation, not just haddock ----------------------------+----------------------------------------------- Reporter: fons | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Comment(by duncan): See additional suggestions in ticket #674. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/330#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0