- cabal-devel - Haskell.org

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

Re: cabal install
by Bjorn Bringert 05 Nov '07

05 Nov '07

On Nov 4, 2007, at 17:10 , Jean-Philippe Bernardy wrote: > Hi, > > I thought I should report this too you: cabal install doesn't work > for me: > (update and list work) > > jp@legolas:~/src$ cabal -v3 install vty > Configuration: > compiler: GHC > repos: hackage.haskell.org:http://hackage.haskell.org/packages/archive > cachedir: "/home/jp/.cabal/packages" > user-install: true > user-prefix: "/home/jp/.cabal" > user-bindir: "$prefix/bin" > user-libdir: "$prefix/lib" > user-libexecdir: "$prefix/libexec" > user-datadir: "$prefix/share" > user-docdir: "$datadir/doc/$pkgid" > user-htmldir: "$docdir/html" > global-prefix: "/usr/local" > global-bindir: "$prefix/bin" > global-libdir: "$prefix/lib" > global-libexecdir: "$prefix/libexec" > global-datadir: "$prefix/share" > global-docdir: "$datadir/doc/$pkgid" > global-htmldir: "$docdir/html" > searching for ghc in path. > found ghc at /home/jp/usr/bin/ghc > ("/home/jp/usr/bin/ghc",["--numeric-version"]) > /home/jp/usr/bin/ghc is version 6.8.1 > looking for package tool: ghc-pkg near compiler in /home/jp/usr/bin > found package tool in /home/jp/usr/bin/ghc-pkg > ("/home/jp/usr/bin/ghc-pkg",["--version"]) > /home/jp/usr/bin/ghc-pkg is version 6.8.1 > searching for ld in path. > found ld at /usr/bin/ld > cabal: dist/Conftest.c: openFile: does not exist (No such file or > directory) > > > Cheers, > JP Hi Jean-Philippe, it works fine for me, but I only have GHC 6.6.1 at the moment. What platform are you on? I'm not sure what the dist/Conftest.c error is about. I'm CC:ing cabal-devel, perhaps some other Cabal hacker can help. /Björn

2 3

patch applied (cabal): Install the haddock interface file to the right place
by Ian Lynagh 03 Nov '07

03 Nov '07

Tue Oct 30 10:02:54 PDT 2007 Ian Lynagh <igloo(a)earth.li> * Install the haddock interface file to the right place M ./Distribution/Simple/Install.hs -1 +10

1 0