- cabal-devel - Haskell.org

[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

Re: [Hackage] #93: Incorrect permissions on library install
by Hackage 27 Jun '09

27 Jun '09

#93: Incorrect permissions on library install ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.1.4 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.10.1 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by GregoryWeber): * status: closed => reopened * ghcversion: 6.4.2 => 6.10.1 * resolution: fixed => Comment: Replying to [comment:7 duncan]: > Fixed in cabal head and the 1.6 branch. > > The behavior now when installing is that we ignore the permissions the files had in the build tree and the user's umask. We explicitly set permissions for all files we install. > That seems to be working well for most files, but those listed in the data-files field of the Cabal package are still installed with permission rw for the owner (root), zero permission for group and others. {{{ [root@squirrel cal3d-examples-0.1]# uname -a Linux squirrel.localdomain 2.6.27.25-170.2.72.fc10.i686 #1 SMP Sun Jun 21 19:03:24 EDT 2009 i686 i686 i386 GNU/Linux [root@squirrel cal3d-examples-0.1]# ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 [root@squirrel cal3d-examples-0.1]# ghc-pkg list Cabal /usr/lib/ghc-6.10.1/./package.conf: Cabal-1.6.0.1 [root@squirrel cal3d-examples-0.1]# runghc Setup install Installing executable(s) in /opt/bin [root@squirrel cal3d-examples-0.1]# cd /opt/share/cal3d-examples-0.1/ [root@squirrel cal3d-examples-0.1]# ls -l total 4 drwxr-xr-x 2 root root 4096 2009-06-27 17:13 data [root@squirrel cal3d-examples-0.1]# ls -l data total 696 -rw------- 1 root root 6400 2009-06-27 17:13 cally_calf_left.cmf -rw------- 1 root root 6464 2009-06-27 17:13 cally_calf_right.cmf -rw------- 1 root root 16968 2009-06-27 17:13 cally_chest.cmf -rw------- 1 root root 210 2009-06-27 17:13 cally_chest.xrf -rw------- 1 root root 3216 2009-06-27 17:13 cally.csf [snip] }}} I can work around this by doing {{{ chmod -Rf g+rX,o+rX . }}} in the source directory where I am developing the package, __before__ building the source tarballs for release. Of course, likewise the installer can do so after unpacking the tarballs, or even after the files are installed. Seems like this might be a big nuisance for projects using darcs with multiple developers, since darcs does not preserve file permissions. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/93#comment:8> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0