September 2010 - cabal-devel

[Hackage] #743: cabal-install boostrap problem: missing: time ==1.1.*
by Hackage 04 Mar '11

04 Mar '11

#743: cabal-install boostrap problem: missing: time ==1.1.* ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.10.4 Platform: Linux | ----------------------------------+----------------------------------------- The bootstrap script does not install the time library, whereas cabal- install depends on it. cabal-install-0.8.2 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/743> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[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] #744: cabal-install depends on time library 1.1.*, whereas 1.2 is default
by Hackage 07 Dec '10

07 Dec '10

#744: cabal-install depends on time library 1.1.*, whereas 1.2 is default ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.10.4 Platform: Linux | ----------------------------------+----------------------------------------- Building cabal-install worked fine for me with the latest version of the time library: 1.2.0.3. I suggest removing the requirement '&& < 1.2' for the time library in cabal-install.cabal. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/744> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[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

darcs patch (manually sent): initial support for building executables with UHC
by Atze Dijkstra 27 Sep '10

27 Sep '10

Apologies for this not 'darcs send' generated format, but I cannot make darcs generate email on my machine which is accepted by the cabal-devel list. This is a patch for adding support for building executables with cabal for UHC. regards, - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 .... | Email: atze(a)cs.uu.nl ............ / |___\

1 0

Darcs repo format
by Daniel Fischer 27 Sep '10

27 Sep '10

Hi, $ darcs get http://darcs.haskell.org/cabal-install/ Converting old-fashioned repository to hashed format... ******************************************************************************* Fetching a hashed repository would be faster. Perhaps you could persuade the maintainer to run darcs optimize --upgrade with darcs 2.4.0 or higher? ******************************************************************************* Can I? Cheers, Daniel

3 3

patch applied (cabal): Bump Cabal version number to 1.10.0.0
by Ian Lynagh 26 Sep '10

26 Sep '10

Thu Sep 23 07:17:31 PDT 2010 Ian Lynagh <igloo(a)earth.li> * Bump Cabal version number to 1.10.0.0 M ./Cabal.cabal -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

darcs patch: Document how Cabal-Version affects behaviour of build-...
by Ben Millwood 25 Sep '10

25 Sep '10

1 patch for repository http://darcs.haskell.org/cabal: Sun Sep 26 03:55:50 BST 2010 Ben Millwood <haskell(a)benmachine.co.uk> * Document how Cabal-Version affects behaviour of build-depends

1 0

[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