March 2009 - cabal-devel

[Hackage] #464: install needs a --package-conf=FILE flag
by Hackage 07 Mar '09

07 Mar '09

#464: install needs a --package-conf=FILE flag ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- It's not possible to use a non-standard package configuration file while installing at the moment. It would be very convenient to have. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/464> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #430: HackageDB is overly pessimistic about HPC.
by Hackage 07 Mar '09

07 Mar '09

#430: HackageDB is overly pessimistic about HPC. --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.3 Platform: | --------------------------------+------------------------------------------- HackageDB wont accept packages that have optional support for HPC. Having packages on Hackage with optional support for HPC can be very useful at times. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/430> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #518: reconfigure command that uses the previous configure command
by Hackage 05 Mar '09

05 Mar '09

#518: reconfigure command that uses the previous configure command ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Sometimes I make a small change to the .cabal file such as adding an exposed module. Cabal then won't let me build without performing a "cabal configure", however I often have a few flags set, so what I'd like to issue instead is: "cabal reconfigure" which means perform a "cabal configure" with the current set of use flags. This would be similar to, and a complement to bug 294. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/518> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: Request to make a validation item on the hackage uploader a soft warning rather than a hard fail
by Andrea Vezzosi 04 Mar '09

04 Mar '09

We resolved to drop support for Cabal < 1.4 in happstack, most users will install using cabal-install anyway. Thanks, Andrea Vezzosi. On Wed, Mar 4, 2009 at 11:52 PM, Matthew Elder <matt(a)mattelder.org> wrote: > Hello All, > > I am trying to upload a release package for happstack 0.2. Right now it > gives me an error because I added dist/build/autogen to my hs-source-dirs. > You can find the output of my error here: > > http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2104#a2104 > > I have been working with Andrea Vezzossi (Saizan) to try to figure out the > best way to handle this situation; he says that this must stay in the .cabal > file to be compatible with Cabal 1.2.4.0 (version that ships with ghc > 6.8.3). Is there any way you guys could make this a soft fail when uploading > to hackage rather than a hard fail? This seems reasonable at least for > awhile until everyone has a chance to upgrade to the latest versions of ghc. > > Thanks in advance guys! > > -- > Need somewhere to put your code? http://patch-tag.com > Want to build a webapp? http://happstack.com >

1 0

[Hackage] #398: better support for static linking
by Hackage 03 Mar '09

03 Mar '09

#398: better support for static linking ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- Generating statically linked binaries on different platforms requires a bit of knowledge about what flags to pass to ghc. It would be nice to just be able to `cabal configure --enable-static-executable` or something and have that pass the extra `-optl-static` and whatever ghc options are required. If it's not possible to generate static binaries it should make some attempt at explaining why. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/398> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #424: build-depends in global section in new-style .cabal files are ignored
by Hackage 03 Mar '09

03 Mar '09

#424: build-depends in global section in new-style .cabal files are ignored ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- http://hpaste.org/12669 In a .cabal file like: {{{ name: music version: 0.0 cabal-version: >= 1.2 build-type: Simple build-depends: base == 4 library exposed-modules: Music }}} which uses new-style syntax but puts the build-depends in the global section, the build-depends get ignored. It should either warn or reject this, or it should automatically propagate such global options into each buildable component. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/424> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #442: remove old packages after successful update
by Hackage 03 Mar '09

03 Mar '09

#442: remove old packages after successful update ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ After a successful `cabal update` command, the old version of the package could be removed. (It required to rebuild/reinstall all the dependent packages as well. It is reported in #441 ticket.) I do not think it should be a default behavior, but make it possible would be really nice. :) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/442> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #470: bad error message when a package transtively depends on two versions of the same one
by Hackage 03 Mar '09

03 Mar '09

#470: bad error message when a package transtively depends on two versions of the same one ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ The following error appears like nonsense: {{{ cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.0 however process-1.0.1.0 was excluded because ghc-6.10.1 requires process ==1.0.1.1 }}} It actually means that there's some package ghc depends on that now is built against the newer process. It should tell the name of the other package(s), too. This is made worse by user-installed packages of the same version shadowing global ones, in this case there is no real error. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/470> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #238: haddock2 is not passed -D__HADDOCK__ or cpp-options
by Hackage 03 Mar '09

03 Mar '09

#238: haddock2 is not passed -D__HADDOCK__ or cpp-options ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- With haddock-1, Cabal invokes cpp, passing it ARCH and OS defines, -D__HADDOCK__ and the contents of cpp-options. However haddock-2 invokes cpp itself via the GHC API, which passes this cpp the ARCH and OS defines, but it doesn't get the others. It might also be a good idea to give __HADDOCK__ a numeric value, because GHC extensions need not be hidden from the new one. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/238> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #189: Handle framework paths (-F) in Cabal
by Hackage 03 Mar '09

03 Mar '09

#189: Handle framework paths (-F) in Cabal --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.1 Platform: Mac OS | --------------------------+------------------------------------------------- There's been some discussion on the GHC trac ([http://hackage.haskell.org/trac/ghc/ticket/1931 1931], [http://hackage.haskell.org/trac/ghc/ticket/1798 1798], [http://hackage.haskell.org/trac/ghc/ticket/1395 1395]) about adding framework search paths (gcc's `-F` flag, and ghc's `-framework-path` flag). Currently Cabal handles `-framework`, but not `-framework-path`. I propose the following behavior for Cabal: 1. Add a `framework-path:` field which will pass `-framework-path` to `ghc` and `-F` to `gcc`, `hsc2hs`, et. al. 2. Always add `-F$HOME/Library/Frameworks` as an argument to the above programs (regardless of any `framework-path` entries). I believe `#1` to be uncontroversial. My reasoning for `#2` is the following: - `$HOME/Library/Frameworks` is the standard location to put frameworks if you do not have administrative access. - Without it, `readline.cabal` (e.g.) would need {{{ framework-path: /Users/judah/Library/Frameworks }}} which is not portable between machines. Finally, note that these flags only affect build behavior, not runtime loading of libraries (which searches `$HOME/Library/Frameworks` by default). See [http://hackage.haskell.org/trac/ghc/wiki/OSXFrameworks OSXFrameworks] for more info. -Judah -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/189> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 13