November 2007 - cabal-devel

Refinements to the Haddock 2 integration
by David Waern 09 Nov '07

09 Nov '07

Hi everyone, Here's a patch that adds (hopefully) correct pre-processing to the Haddock 2 command. It should really be added to the Haddock < 2 path as well (which AFAIK doesn't do any pre-processing except for CPP and Unlit), but I've avoided this because of the risk of introducing bugs in the much-used Haddock < 2 path. In the future this code will be replaced by the new make system anyway. The patch also adds CPP include paths and output paths to the commands sent to GHC (via Haddock). The output paths are needed if certain changes to the GHC API don't make it into GHC 6.8.2. With this patch I'm now able to process all boot and core libs of GHC 6.8.1 including base (with a small patch for its Setup.lhs). Hopefully we can get it into the next version of Cabal bundled with GHC. David

1 0

patch applied (cabal): Add extensions that ghc-6.6 supports
by Duncan Coutts 09 Nov '07

09 Nov '07

Fri Nov 9 06:22:50 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Add extensions that ghc-6.6 supports M ./Distribution/Simple/GHC.hs -1 +13

1 0

patch applied (cabal): The extension is NoMonoPatBinds not MonoPatBinds
by Duncan Coutts 09 Nov '07

09 Nov '07

Fri Nov 9 06:22:17 PST 2007 Duncan Coutts <duncan(a)haskell.org> * The extension is NoMonoPatBinds not MonoPatBinds M ./Language/Haskell/Extension.hs -1 +1

1 0

patch applied (cabal): Add language extensions introduced in GHC 6.8
by Duncan Coutts 09 Nov '07

09 Nov '07

Thu Nov 8 10:56:12 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Add language extensions introduced in GHC 6.8 M ./Language/Haskell/Extension.hs +18

1 0

patch applied (cabal): Make the ld -x test use the temp dir rather than dist dir
by Duncan Coutts 08 Nov '07

08 Nov '07

Thu Nov 8 06:13:49 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Make the ld -x test use the temp dir rather than dist dir Should fix cabal-install. M ./Distribution/Simple/GHC.hs -13 +16

1 0

Re: [Hackage] #160: PatternSignatures missing in Extensions
by Hackage 07 Nov '07

07 Nov '07

#160: PatternSignatures missing in Extensions ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: high | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: very easy (<1 hour) Ghcversion: 6.6 | Platform: Linux ---------------------+------------------------------------------------------ Changes (by duncan): * milestone: => Cabal-1.2 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/160#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #160: PatternSignatures missing in Extensions
by Hackage 07 Nov '07

07 Nov '07

#160: PatternSignatures missing in Extensions ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: very easy (<1 hour) Ghcversion: 6.6 | Platform: Linux ---------------------+------------------------------------------------------ Comment (by guest): The thing is, this particular one is a regression - code that used to compile with Cabal on ghc 6.6.1 can't be compiled with Cabal on ghc 6.8.1, because the shipped Cabal doesn't have the PatternSignatures extension (which you didn't used to have to specify). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/160#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #160: PatternSignatures missing in Extensions
by Hackage 06 Nov '07

06 Nov '07

#160: PatternSignatures missing in Extensions ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: very easy (<1 hour) Ghcversion: 6.6 | Platform: Linux ---------------------+------------------------------------------------------ Comment (by duncan): See also: http://www.haskell.org/pipermail/libraries/2007-November/008542.html which has the full list of extensions that ghc-6.8.1 introduced and which I propose to add to the Language.Haskell.Extensions enumeration. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/160#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Fwd: [patch: PatternSignatures] [greenrd@greenrd.org]
by Ian Lynagh 06 Nov '07

06 Nov '07

1 0

suggestion for a small extension to configurations
by Duncan Coutts 05 Nov '07

05 Nov '07

With the current issue of the split base library we have a lot of code like: flag split-base library if flag(split-base) build-depends: base >= 3.0, pretty, directory, etc else build-depends: base < 3.0 This does a backtracking search, checking both alternatives to see if one is satisfiable. It's a bit unsatisfactory however since we have to introduce a flag for a choice which really should be automatic and not visible to the user. It was always a deliberate part of the design of configurations that we should not let package authors make automatic decisions without the environment (packager or user) being able to influence the choice. So the question is, is there a special case that we can say really is an automatic decision that the user does not need to control with a flag? Here's my suggestion: library build-depends: base if package(base >= 3) build-depends: pretty, directory, etc and it is syntactic sugar for: flag _unnamed1 library build-depends: base if flag(_unnamed1) build-depends: base >= 3.0 build-depends: pretty, directory, etc else build-depends: !(base >= 3.0) So we introduce a new predicate 'package()' that tests the version number of a package that we've already declared that we depend on. It is crucial that it be one we already depend upon. It does not test packages in the environment generally, it tests the version of the package that the environment has or might impose. So we still introduce a backtracking point, it's just that now it's an backtracking without a named flag. This is ok because the decision about which branch to take is completely determined once the environment picks a version for the dependent package in question. Details... each package predicate test introduces it's own distinct anonymous flag. The flags are introduced in order, top to bottom, left to right and appear after all other named flags. eg: flag blah build-depends: foo, bar if package(foo > 1) && package (bar > 1) && flag(blah) ... else ... => flag blah flag _1 flag _2 build-depends: foo, bar if flag(_1) && flag(_2) && flag(blah) build-depends: foo > 1 build-depends: bar > 1 ... else build-depends: !(foo > 1) build-depends: !(bar > 1) ... Saying that we already depend on a package is interpreted relative to the position of the package() test in the overall condition tree. It means that to get to the branch where the package() test is, we must have that package in the build-depends explicitly in some parent node. Possibly as an extension we could allow it to appear in all the alternatives of some sibling node eg: So, overall, does that make sense? Is that sufficiently precise? Should we do it? Here's the canonical example. It's a package (tar) that works with ghc-6.4, 6.6 and 6.8 and uses bytestring: Flag bytestring-in-base Flag split-base library if flag(bytestring-in-base) -- bytestring was in base-2.0 and 2.1.1 build-depends: base >= 2.0 && < 2.2 else -- in base 1.0 and 3.0 bytestring is a separate package build-depends: base < 2.0 || >= 3, bytestring >= 0.9 if flag(split-base) build-depends: base >= 3.0, directory, old-time else build-depends: base < 3.0 which we could simplify to: library build-depends: base if package(base >= 3) directory, old-time if package(base < 2 || >= 3) build-depends: bytestring >= 0.9 Much nicer I think. Duncan

3 3