August 2010 - cabal-devel

[Hackage] #676: bash-completion gets confused by alias for rm
by Hackage 05 Jan '12

05 Jan '12

#676: bash-completion gets confused by alias for rm ---------------------------------+------------------------------------------ Reporter: benmachine | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: minor | Keywords: Difficulty: unknown | Ghcversion: 6.12.1 Platform: Linux | ---------------------------------+------------------------------------------ I have an alias for rm defined so that it is by default verbose (alias rm='rm -v' in my bashrc). When I do cabal install has<tab> I get something like: [ben@euler ~]$ cabal install hasbash: bad substitution: no closing "`" in `/tmp/cabal_completion.tD2o8O' It turns out that rm is helpfully going: removed `/tmp/cabal_completion.hb1zbc' and then cabal is trying to use this as part of the completion command - choking on the ` because bash thinks it is part of a substitution. So rm should probably explicitly discard its stdout. While I was there I noticed that "cat" is used redundantly. There's nothing really wrong with this so that part of the patch can be cut I suppose, but I thought it was neater to use bash's input redirection explicitly. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/676> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #677: Error: Couldn't read cabal file "./HDBC/2.2.5/HDBC.cabal"
by Hackage 05 Jan '12

05 Jan '12

#677: Error: Couldn't read cabal file "./HDBC/2.2.5/HDBC.cabal" ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.10.4 Platform: Linux | ---------------------------------+------------------------------------------ I recently upgraded cabal-install and started getting this error: $ cabal install HDBC Resolving dependencies... cabal: Couldn't read cabal file "./HDBC/2.2.5/HDBC.cabal" I also get the same error when I try to install one of my own packages that depends on HDBC. I tried changing my HDBC dependency to == 2.2.2 as well as >= 2.2.6, but still get the same error for version 2.2.5. I have cabal-install version 0.6.2 and Cabal version 1.6.0.3. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/677> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #674: Findable extra documentation
by Hackage 05 Jan '12

05 Jan '12

#674: Findable extra documentation ----------------------------+----------------------------------------------- Reporter: jbapple | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I have a cabal package that should include extra documentation in the distribution. This documentation should not be written in Haddock. 1. There should be a field for this analogous to data-files or extra- source-files. The former is too much: the files do not need to be accessed by any Haskell runtime. The latter is not enough: it does not store the extracted files on the system on which the package is installed. 2. There should be a way for humans to find these files without loading up a GHC runtime or using Unix's "find". I suggest "cabal list" also shows, for installed packages with extra data or documentation files installed, where these files can be found. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/674> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #722: Data-Files cabal directive should support directories
by Hackage 30 Jan '11

30 Jan '11

#722: Data-Files cabal directive should support directories ----------------------------+----------------------------------------------- Reporter: cygnus | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: recursive directories data sdist Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- It should be possible to use the `Data-Files` directive to include whole directories (recursively) in source distributions. In many cases it's impossible or cumbersome to list all of the files one would like to install, and it seems to me that nobody should have to do that if what they really mean is, "install everything in that-data-dir/." In implementation terms, this doesn't strike me as too tricky; after the wildcard parsing that already happens, detect whether the files to be copied are in fact directories and copy them recursively as such. I'm more than willing to hack on this. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/722> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #704: sort out design for foreign code in Haskell libraries
by Hackage 09 Nov '10

09 Nov '10

#704: sort out design for foreign code in Haskell libraries ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Currently we often happily add little bits of C glue code into Haskell packages. This is perfectly reasonably but we also want to be able to do things like linking multiple versions of a Haskell package into a single application. That does not work if the C symbols are visible outside of the package (see #701). It seems reasonable to require that C code in a Haskell package respects the properties that we want for Haskell packages. However we must also allow for libraries that are foreign code and not Haskell libraries at all. For example, the zlib binding package ships a complete copy of the zlib C code for platforms that do not have it natively. Unlike bits of FFI glue code, it is unreasonable to expect to change the zlib code to conform to Haskell library requirements. Perhaps what we need is to explicitly identify foreign libraries and hold them to different (lower) standards compared to Haskell libraries. One idea would be to draw together the features proposed in these tickets: * #276 : support for convenience libraries * #148 : producing foreign libraires The idea with convenience libraries is that a package can have multiple libraries in it, even though at most one can be the library that has exposed modules. Other libraries could be used by executables or the main library in that package. The main purpose is sharing but it could also be a way to separate the requirements of haskell code and foreign code. Producing foreign libraries is about making libraries (usually but not necessarily containing Haskell code) that export a foreign C API and are not intended to be used by other Haskell code. Combining these two features would allow for the zlib example to work ok. We would declare a foreign library with the zlib C code and make the main Haskell binding library depend on it. Note that packages that depend on the binding package would not directly link to the C library (this is significant for shared libs). The key constraint for foreign libraries is that we cannot link more than one version into a single application (because the symbols would clash), where as we may assume that it is perfectly safe to link multiple versions of a Haskell package. Any design must also consider symbol visibility. This is relevant both for shared and static libs. With static libs it is hard to avoid every symbol being globally visible. With shared libs there is greater control over symbol visibility but also the restriction on some systems that each shared lib must resolve all symbol references. This means we must more explicitly identify which libraries import symbols from others. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/704> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Package Dependency License Checking
by Trevor Elliott 10 Oct '10

10 Oct '10

Hi Everyone, I have started implementing a license compatibility check in Cabal, and was interested in getting some early feedback. The attached patch will, as part of the configure step, check that the dependencies have licenses that are compatible with the license chosen for the package being configured. No errors are thrown as a result of incompatible licenses, though warnings are printed. Thanks, --trevor

2 1

[Hackage] #666: configure should warn about using base 3
by Hackage 24 Sep '10

24 Sep '10

#666: configure should warn about using base 3 ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- http://haskell.org/pipermail/haskell-cafe/2010-April/076823.html For backwards compatibility we make cabal-install prefer base 3 if there is no upper bound on the version of base. This is necessary however it is also confusing. People writing new packages should be getting base 4. We want to encourage people to use base 4, as version 3 is deprecated. We should make `cabal configure` warn if base 3 is selected since this is deprecated. The message should indicate the appropriate solution, ie to put an upper bound on the version of base. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/666> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #656: Cabal-1.8-style dependencies stop Haddock from working
by Hackage 27 Aug '10

27 Aug '10

#656: Cabal-1.8-style dependencies stop Haddock from working ------------------------------+--------------------------------------------- Reporter: Ivan Miljenovic | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ------------------------------+--------------------------------------------- Changes (by sebf): * cc: mail@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/656#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #630: Please add support for common modules and options
by Hackage 27 Aug '10

27 Aug '10

#630: Please add support for common modules and options -----------------------------------+---------------------------------------- Reporter: AnttiJuhaniKaijanaho | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal specification | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -----------------------------------+---------------------------------------- Changes (by sebf): * cc: mail@… (added) Comment: Ideally, a build system would not only be purely functional but lazy: if two executables list common modules under `Other-Modules` and the compile options are the same then the common modules should be compiled only once. I think this should happen automatically without user intervention. The proposed `All-Executables` section would help reduce duplication in cabal files but I don't think it should be necessary to share compilation results for multiple executables without making a library to depend upon. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/630#comment:1> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

27 Aug '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 sebf): * cc: mail@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:38> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0