June 2010 - cabal-devel

[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

[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 Jun '10

27 Jun '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 | ------------------------------+--------------------------------------------- Comment(by guest): I had the same problem with the current version 1.8.0.6 from Hackage. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/656#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #411: Command to install dependencies of a package.
by Hackage 24 Jun '10

24 Jun '10

#411: Command to install dependencies of a package. ---------------------------------+------------------------------------------ Reporter: mornfall | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.8 Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Comment(by mornfall): The workaround from 11 months ago does not work with current cabal anymore. The script has gotten considerably uglier, see contrib/install- deps.sh in darcs darcs repo (darcs get http://darcs.net) A patch to cabal-install is of course better, so we can probably close this as superseded by #697? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/411#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #411: Command to install dependencies of a package.
by Hackage 24 Jun '10

24 Jun '10

#411: Command to install dependencies of a package. ---------------------------------+------------------------------------------ Reporter: mornfall | Owner: Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.8 Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ Comment(by duncan): Patch for this in #697. Above suggestion is interesting too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/411#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #689: Package checker shouldn't warn about deprecated extensions inside conditionals
by Hackage 22 Jun '10

22 Jun '10

#689: Package checker shouldn't warn about deprecated extensions inside conditionals --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: hackageDB website | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | --------------------------------+------------------------------------------- Hello, I uploaded a package to Hackage (extcore 0.6) that contains the following text in the Library section in the .cabal file: {{{ if impl(ghc > 6.8.2) { build-depends:syb } else { extensions: PatternSignatures } }}} The Hackage package checker warned me: "Deprecated extensions: 'PatternSignatures'. Instead of 'PatternSignatures' use 'ScopedTypeVariables'." This seems like a bug to me. Of course PatternSignatures is deprecated; that's why it's in a clause that only applies with a version of GHC less than 6.8.2. Warnings should trigger only for extensions that are deprecated in the version that the extension is declared for. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/689> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

Re: [Hackage] #642: [ghc-6.12] support dynamic linking of executables
by Hackage 22 Jun '10

22 Jun '10

#642: [ghc-6.12] support dynamic linking of executables ----------------------------+----------------------------------------------- Reporter: juhp | Owner: Type: defect | Status: closed Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Resolution: duplicate Keywords: | Difficulty: unknown Ghcversion: | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => duplicate -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/642#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #627: sdist drops executable permissions for files in the tarball (was: Nonsense tarball permissions with sdist in Cabal 1.8.0.2)
by Hackage 22 Jun '10

22 Jun '10

#627: sdist drops executable permissions for files in the tarball ----------------------------+----------------------------------------------- Reporter: draconx | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ----------------------------+----------------------------------------------- Comment(by duncan): Note also that cabal unpack does not preserve any executable permissions. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/627#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #589: FreeBSD compiles should automatically add --extra-lib-dirs=/usr/local/lib
by Hackage 22 Jun '10

22 Jun '10

#589: FreeBSD compiles should automatically add --extra-lib-dirs=/usr/local/lib ----------------------------+----------------------------------------------- Reporter: markstos | Owner: Type: defect | Status: new Priority: low | Milestone: _|_ Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Changes (by duncan): * priority: normal => low Comment: Nothing is going to happen with this ticket unless we get some feedback from FreeBSD users/developers. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/589#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #263: Multiple compilers of the same version confuse Cabal
by Hackage 22 Jun '10

22 Jun '10

#263: Multiple compilers of the same version confuse Cabal ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: _|_ Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: very hard (<1 week) | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- Comment(by duncan): Note that with ghc-6.12 this problem is less significant because ghc+cabal will detect the inconsistency before there is a chance of segfaults. This is because the package ABI hashes are now tracked. If in future we install with the ABI hash as part of the install directory then the problem would be fully solved. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/263#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0