May 2011 - cabal-devel

[Hackage] #754: cabal should pass extra lib/include dirs to configure scripts
by Hackage 03 Mar '12

03 Mar '12

#754: cabal should pass extra lib/include dirs to configure scripts ---------------------------------+------------------------------------------ Reporter: simonmic | 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: | ---------------------------------+------------------------------------------ cabal install SDL-gfx with macports has always failed for me, because that package's configure script doesn't know about the required extra lib dir /opt/local/lib. This made it work: LDFLAGS=-L/opt/local/lib cabal install SDL-gfx . cabal-install should probably use this or some other method to tell configure scripts about extra lib and include dirs. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/754> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #759: please clarify/document --remote-repo
by Hackage 03 Mar '12

03 Mar '12

#759: please clarify/document --remote-repo ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I often find myself writing example code that I'd like to distribute via cabal, but without further burdening hackage with not generally useful packages. The source code has an undocumented(?) option `--remote-repo` that seems to serve that purpose, but there is little documentation, sometimes conflicting info, about how to put this to use. Mailing list threads: http://www.haskell.org/pipermail/haskell-cafe/2010-November/085860.html http://www.haskell.org/pipermail/haskell-cafe/2010-November/085900.html Repo layout descriptions (differs between hackage 1.0 and 2.0, which is hardcoded in `cabal-install`): http://hackage.haskell.org/trac/hackage/wiki/HackageDB http://hackage.haskell.org/trac/hackage/wiki/HackageDB/2.0/URIs Related tickets: #758, comment:6:ticket:428 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/759> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #761: could use more options for framework linking on mac
by Hackage 03 Mar '12

03 Mar '12

#761: could use more options for framework linking on mac ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Mac OS | ---------------------------------+------------------------------------------ It seems you can list apple frameworks in a .cabal file like other libs, but I'm not sure how to influence where cabal looks for those frameworks. When trying to link with some in a non-standard place, I wished for an --extra-framework-dirs option. There is a rumoured -framework option, I haven't found much info in --help or online about all this. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/761> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #755: high verbosity should make configure verbose as well ?
by Hackage 03 Mar '12

03 Mar '12

#755: high verbosity should make configure verbose as well ? ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Even with -v 3, configure scripts run at normal verbosity which is often not enough to debug the problem. AFAIK you have to unpack the package, install/configure again and inspect config.log. If possible it would be convenient to have -v2 or -v3 tell configure to print the full log on stdout. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/755> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #725: Distinguish speculative and required build-depends upper bound
by Hackage 03 Mar '12

03 Mar '12

#725: Distinguish speculative and required build-depends upper bound ---------------------------------+------------------------------------------ Reporter: ezyang | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ When a package adds a build-dependency on another package, it's good form to follow the Package Versioning Policy and add a speculative upper bound that is x.(y+1), if the current version is x.y. This is great, but in many cases the next version will /not/ break compatibility with your package. In that case, once you have tested that the dependency is fine, you can bump the upper bound. As the list of dependencies for any respectable Cabal package can be quite long, it may be useful to have some sort of 'cabal whatsnew' command which checks the upper bounds of your build dependencies and notifies you when there are newer versions than your upper bounds availble. Furthermore, there should be a mechanism for telling Cabal that the upper bound is required, and that the package will break if you try to bump it. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/725> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #768: Cabal cannot find GHC when using relative path in -w flag
by Hackage 03 Mar '12

03 Mar '12

#768: Cabal cannot find GHC when using relative path in -w flag ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Trying to build the network package while standing at the root of a GHC build tree fails to find GHC: {{{ $ cabal install -w inplace/bin/ghc-stage2 network -v2 inplace/bin/ghc-stage2 --numeric-version looking for package tool: ghc-pkg near compiler in inplace/bin found package tool in inplace/bin/ghc-pkg inplace/bin/ghc-pkg --version inplace/bin/ghc-stage2 --supported-languages Reading installed packages... inplace/bin/ghc-pkg dump --global inplace/bin/ghc-pkg dump --user inplace/bin/ghc-stage2 --print-libdir Reading available packages... Resolving dependencies... selecting network-2.3 (hackage) and discarding network-2.0, 2.1.0.0, 2.2.0.0, 2.2.0.1, 2.2.1, 2.2.1.1, 2.2.1.2, 2.2.1.3, 2.2.1.4, 2.2.1.5, 2.2.1.6, 2.2.1.7, 2.2.1.8, 2.2.1.9, 2.2.1.10, 2.2.3 and 2.2.3.1 selecting base-4.3.0.0 (installed) selecting ffi-1.0 (installed) selecting ghc-prim-0.2.0.0 (installed) selecting integer-gmp-0.2.0.2 (installed) selecting rts-1.0 (installed) selecting parsec-2.1.0.1 (hackage) and discarding parsec-2.0, 2.1.0.0, 3.0.0, 3.0.1 and 3.1.0 selecting unix-2.4.1.0 (installed) and discarding unix-2.0, 2.2.0.0, 2.3.0.0, 2.3.1.0, 2.3.2.0, 2.4.0.0, 2.4.0.1 and 2.4.0.2 selecting bytestring-0.9.1.8 (installed) and discarding bytestring-0.9, 0.9.0.1, 0.9.0.2, 0.9.0.3, 0.9.0.4, 0.9.1.0, 0.9.1.1, 0.9.1.2, 0.9.1.3, 0.9.1.4, 0.9.1.5, 0.9.1.6 and 0.9.1.7 In order, the following would be installed: parsec-2.1.0.1 (new package) network-2.3 (new package) parsec-2.1.0.1 has already been downloaded. Extracting /home/tibell/.cabal/packages/hackage.haskell.org/parsec/2.1.0.1/parsec-2.1.0.1.tar.gz to /tmp/parsec-2.1.0.117969... Configuring parsec-2.1.0.1... cabal: Cannot find the program 'ghc' at 'inplace/bin/ghc-stage2' or on the path cabal: Error: some packages failed to install: network-2.3 depends on parsec-2.1.0.1 which failed to install. parsec-2.1.0.1 failed during the configure step. The exception was: ExitFailure 1 }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/768> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #781: cabal list should have --with-compiler, --user, --global and --package-db flags
by Hackage 03 Mar '12

03 Mar '12

#781: cabal list should have --with-compiler, --user, --global and --package-db flags ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ `cabal list` is lacking a way to control which compiler and package databases are queried. See also ticket #457 about enhanced filtering for `cabal list` -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/781> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #809: Improve update performance
by Hackage 03 Mar '12

03 Mar '12

#809: Improve update performance ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I have an automated package build set up using Hudson, and it tries to build my code as often as once every 5 minutes. Right now, that means running cabal update before every build, which takes at least 30 seconds. It would be great if cabal update used the ETag and If-Modified-Since HTTP headers to do conditional fetches of the metadata, so that there would be far less of a performance hit to both the Hackage server and my client. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/809> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #818: cabal sdist warns about optimization levels
by Hackage 03 Mar '12

03 Mar '12

#818: cabal sdist warns about optimization levels ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.1.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ For some reason 'cabal sdist' dislikes fast code so much that it tells me not to use -O2. What does it know about my needs and my project? See below for an example: {{{ $ cabal sdist Distribution quality warnings: 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit and not just imposing longer compile times on your users. }}} Is there a way to disable this warning in my .cabal file? If not, can the warning please be removed? It doesn't seems appropriate for sdist to tell me which compiler flags I should use to optimize my code. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/818> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #820: cabal-install clobbers itself on multi-arch platforms
by Hackage 03 Mar '12

03 Mar '12

#820: cabal-install clobbers itself on multi-arch platforms ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ On my Mac, I have 32-bit and 64-bit versions of GHC 7.0.2 installed, and cabal installs the object and interface files into the same directory. The {{{$arch}}} variable looks like it should do the right thing, but in fact it's expanded to whatever architecture cabal-install was built for, not the architecture that's supported by GHC itself. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/820> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3