- cabal-devel - Haskell.org

patch applied (cabal): TAG 2009-06-25
by Ian Lynagh 05 Jul '09

05 Jul '09

Thu Jun 25 09:01:44 PDT 2009 Ian Lynagh <igloo(a)earth.li> tagged 2009-06-25 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090625160144-3fd76-46011c8b…

1 0

[Hackage] #563: absoluteInstallDirs changed signature, breaks darcs Setup
by Hackage 05 Jul '09

05 Jul '09

#563: absoluteInstallDirs changed signature, breaks darcs Setup ----------------------------+----------------------------------------------- Reporter: mornfall | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- In Cabal 1.7.2 (i.e. recent HEAD), I get: Setup.lhs:168:43: Couldn't match expected type `Distribution.Package.PackageId' against inferred type `PackageDescription' In the first argument of `absoluteInstallDirs', namely `pkg' In the first argument of `mandir', namely `(absoluteInstallDirs pkg lbi copy)' In the first argument of `(</>)', namely `mandir (absoluteInstallDirs pkg lbi copy)' (This works as expected with Cabal 1.6.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/563> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal): Undo a simplification in the type of absoluteInstallDirs
by Duncan Coutts 05 Jul '09

05 Jul '09

Sun Jul 5 08:41:55 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Undo a simplification in the type of absoluteInstallDirs Existing Setup scripts use it so we can't change it. Fixes #563. M ./Distribution/Simple/Build/PathsModule.hs -1 +1 M ./Distribution/Simple/Configure.hs -1 +1 M ./Distribution/Simple/Install.hs -2 +2 M ./Distribution/Simple/LocalBuildInfo.hs -3 +3 M ./Distribution/Simple/Register.hs -4 +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090705154155-adfee-71eafca2…

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 05 Jul '09

05 Jul '09

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn(a)bringert.net | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by maltem): Splendid, thanks for the explanation. Also, looking forward to 1.8 :) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:17> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 05 Jul '09

05 Jul '09

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn(a)bringert.net | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by blackh): * status: new => assigned * owner: => blackh Comment: maltem, the work on ticket 89 is completed and checked except for some minor bits that are not quite finished. However, the error message is telling lies. The minimum version for the ticket 89 feature to be activated is actually 1.7.1. (I assume the reason for this little porkie is that Duncan is intending 1.8 to be the version when it is released.) So, to test it, use: cabal-version: >= 1.7.1 Another point is that GHC will always look in the build directory in preference to using a library, so if you want to make it treat your internally defined library just like an external one (and therefore build each source file only one), you have to use hs-source-dirs: programs or similar on either your library or executable definition or both with different directory names, to keep the source files separate. There's an example of this in cabal/tests/PackageTests/BuildDeps/InternalLibrary1 - Stephen Blackheath -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:16> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 03 Jul '09

03 Jul '09

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn(a)bringert.net | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by maltem): I tried to test the new feature, but the current version in darcs is 1.7.2, so configuring a package fails: Error: This package requires Cabal version: >=1.8 This is what I did, did I do something wrong? Or should I just “adjust” the version number for the test? darcs get --partial http://darcs.haskell.org/cabal/ cd cabal cabal install cd ../my_package ghc --make Setup -package Cabal-1.7.2 ./Setup configure -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:15> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #330: Take non-haddock documentation in account
by Hackage 01 Jul '09

01 Jul '09

#330: Take non-haddock documentation in account ----------------------------+----------------------------------------------- Reporter: fons | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The generation and installation of Non-Haddock documentation (README and INSTALL files, LaTeX and Docbook tutorials/guides, Haskell examples using the package in question) is not currently taken in account by Cabal. Making Cabal understand how to generate documentation for all those formats would probably be too ambitious, but it could be eased (e.g. letting the user provide Makefiles instead of creating custom hooks). More importantly, the installation of documentation would be much easier with a new package property such as "doc-files" ("data-files" nor "extra- source-files" are semantically suitable). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/330> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

Dependencies from .cabal files
by Erik de Castro Lopo 01 Jul '09

01 Jul '09

Hi all, I hope this is the right list to ask this. Please direct me to the right place if not. Anyway, I'm using functionality in the Distribution.* namespace to parse .cabal files retrieved from Hackage. The problem is that after using flattenPackageDescription, the buildDepends of the PackageDescription structure seems to be a flat list which seems to lose information that was in the original .cabal file. For instance, the cabal file for hoogle, contains: build-depends: parsec, filepath, safe, uniplate, mtl, time if flag(splitBase) build-depends: base >= 3, directory, process, containers, array, bytestring else build-depends: base < 3 while the buildDepends list looks like this: Dependency (PackageName "base") (EarlierVersion (Version {versionBranch = [3], versionTags = []})), Dependency (PackageName "bytestring") AnyVersion, Dependency (PackageName "array") AnyVersion, Dependency (PackageName "containers") AnyVersion, Dependency (PackageName "process") AnyVersion, Dependency (PackageName "directory") AnyVersion, Dependency (PackageName "base") (UnionVersionRanges (ThisVersion (Version {versionBranch = [3], versionTags = []})) (LaterVersion (Version {versionBranch = [3], versionTags = []}))), Dependency (PackageName "time") AnyVersion, Dependency (PackageName "mtl") AnyVersion, Dependency (PackageName "uniplate") AnyVersion, Dependency (PackageName "safe") AnyVersion, Dependency (PackageName "filepath") AnyVersion, Dependency (PackageName "parsec") AnyVersion Should the conversion from .cabal file to Dependency list be lossy? I look forward to enlightenment. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

2 3

[Hackage] #325: SHGetFolderPath requiered to configure cabal 1.4
by Hackage 30 Jun '09

30 Jun '09

#325: SHGetFolderPath requiered to configure cabal 1.4 ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- i try to install cabal with ghc 6.8.3 on XP. i get the error message GHCi could not find the following symbols SHGetFolderPath i saw some old bugs mentioning this problem - what is a current fix? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/325> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

patch applied (cabal): Help Cabal find gcc/ld on Windows
by Simon Marlow 29 Jun '09

29 Jun '09

Fri Jun 26 07:02:50 PDT 2009 Simon Marlow <marlowsd(a)gmail.com> * Help Cabal find gcc/ld on Windows Ignore-this: bad21fe3047bc6e23165160c88dd53d9 the layout changed in the new GHC build system M ./Distribution/Simple/GHC.hs -8 +18 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090626140250-12142-118d9aa8…

1 0