September 2009 - cabal-devel

patch applied (cabal): Modify foldVersionRange and add foldVersionRange'
by Duncan Coutts 17 Sep '09

17 Sep '09

Wed Sep 16 20:27:13 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Modify foldVersionRange and add foldVersionRange' Ignore-this: cdb7ff28869dd8637cbc7d1a02620c5b Now foldVersionRange gives a view with no syntactic sugar while foldVersionRange' gives a view with the syntactic sugar. M ./Distribution/PackageDescription/Check.hs -6 +11 M ./Distribution/Version.hs -8 +56 M ./tests/Test/Distribution/Version.hs -6 +49 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090917032713-adfee-12ffd86c…

1 0

patch applied (cabal): Fix the version-range parser to allow arbitrary expressions over constraints.
by Duncan Coutts 17 Sep '09

17 Sep '09

Fri Sep 11 04:16:43 PDT 2009 Malcolm.Wallace(a)cs.york.ac.uk * Fix the version-range parser to allow arbitrary expressions over constraints. Previously, only a single conjunction (&&) or disjunction (||) was parseable, despite an internal representation that permits arbitrary combinations. Now, any sequence of (&&) and (||) combining forms is parsed. (&&) binds more tightly than (||). M ./Distribution/PackageDescription/Check.hs -1 +18 M ./Distribution/Version.hs -19 +28 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090911111643-6871e-da3af91a…

1 0

darcs patch: Fix the version-range parser to allow arbitrary expres...
by Malcolm.Wallace＠cs.york.ac.uk 17 Sep '09

17 Sep '09

Thu Sep 10 20:09:12 BST 2009 Malcolm.Wallace(a)cs.york.ac.uk * Fix the version-range parser to allow arbitrary expressions over constraints. Previously, only a single conjunction (&&) or disjunction (||) was parseable, despite an internal representation that permits arbitrary combinations. Now, any sequence of (&&) and (||) combining forms is parsed. (&&) binds more tightly than (||).

5 6

[Hackage] #585: specify hidden modules as everything not exposed
by Hackage 16 Sep '09

16 Sep '09

#585: specify hidden modules as everything not exposed ----------------------------+----------------------------------------------- Reporter: wisnesky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I'm trying to package a large Haskell project (currently built using make) to Cabal, and although we only want to expose around a dozen modules, the implementation of those modules uses hundreds of other modules. It seems like I need to explicitly list each of these hidden modules in the .cabal file in order to generate a library that will link correctly. Ideally, I could just say what the exposed modules are, and have every other module hidden by default. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/585> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #584: adding arbitrary .o files to the static archive
by Hackage 15 Sep '09

15 Sep '09

#584: adding arbitrary .o files to the static archive ----------------------------+----------------------------------------------- Reporter: wisnesky | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Cabal's Simple build system does not currently provide any mechanism for adding arbitrary .o files into the static archive and similarly no way to link one static archive with another. The only builtin mechanism is to compile C code (specified by the "c-sources" field) and that gets included into the same static archive as the Haskell library. I would like to request this feature. Here is a more detailed description: Adding an extra-libraries field to a cabal source package description: {{{ Name: LibraryFoo ... Library Extra-libraries: Bar }}} has the effect that when loading package LibraryFoo in ghci, ghci will necessarily try to open a corresponding Bar.so/.dll/.dylib file: {{{ > ghci -package LibraryFoo Loading package LibraryFoo-0.1 ... <command line>: can't load .so/.DLL for: Bar (dlopen(Bar.dylib, 10): image not found) }}} What I want to do is statically link LibraryFoo against Bar before Cabal installs the package, (so that, for instance, I can run ghci without a bunch of command line linking arguments and don't need to have Bar around anymore), and I have a Bar.o file for just such a purpose. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/584> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #583: create application bundles on demand
by Hackage 11 Sep '09

11 Sep '09

#583: create application bundles on demand ----------------------------+----------------------------------------------- Reporter: kowey | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Mac OS | ----------------------------+----------------------------------------------- Currently, getting graphical applications to work on MacOS X involves a bit of manual steps after "cabal install", particularly if the applications happen to be command line oriented at the same time (ie. a GUI that supports being called from the command line). The blog post below offers a solution which seems to work for wxHaskell (Setup.hs files also attached). Perhaps it can be generalised somehow so that users can just tell Cabal they want an application bundle? Duncan requested Apple docs on application bundles. I haven't read it yet, but maybe this will help? * Blog post: http://koweycode.blogspot.com/2009/09/cabal-installing- graphical-apps-on.html * Bundle Programming Guide: http://developer.apple.com/mac/library/documentation/CoreFoundation/Concept… -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/583> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #240: setup install does not preserve MacOS X resource forks
by Hackage 11 Sep '09

11 Sep '09

#240: setup install does not preserve MacOS X resource forks ----------------------------+----------------------------------------------- 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 use the attached Setup.lhs file to do some Mac-related magic (which I unfortunately do not understand) on files built with wxhaskell on MacOS X. The key point about this magic is that it allows me to run a GUI from the command line. Without doing the magic, the GUI will open, but it will not react to any user interaction. I think the problem is that whatever mechanism we use to copy the binary over (say to /usr/local/bin) does not preserve the magic. That is, if I run it directly after a runhaskell Setup install, I get the non-reactive GUI. If I do a cp geni /usr/local/bin by hand, then the GUI reacts, presumably because on MacOS X cp also copies the magic over. Sorry for being so vague. Let me know if I can help in any way. -- Eric Kow -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/240> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #582: cabal-install not installing packages listed as upgradable
by Hackage 11 Sep '09

11 Sep '09

#582: cabal-install not installing packages listed as upgradable ---------------------------------+------------------------------------------ Reporter: Raevel | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ My terminal session probably describes the problem best: {{{ $ cabal update Downloading the latest package list from hackage.haskell.org $ cabal upgrade *snip* Below is the list of packages that it would have tried to upgrade. You can use the 'install' command to install the ones you want. Note that it is generally not recommended to upgrade core packages. *snip* parsec $ cabal install parsec Resolving dependencies... No packages to be installed. All the requested packages are already installed. If you want to reinstall anyway then use the --reinstall flag. }}} This also applies to other packages. The problem seems to be because i have parsec 2.x installed, and 3.x is available, `cabal install parsec==3.0.1` removes the parsec line from cabal upgrade. I expect one of the following behaviors: * cabal upgrade should tell me that install won't suffice since it's a major update, and that 3.0.1 is available. * cabal install should install 3.0.1 for me. * cabal upgrade should not list the package at all. I'm not sure which one is the best. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/582> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): Use -package-id rather than -package with GHC 6.11+
by Simon Marlow 09 Sep '09

09 Sep '09

Sun Sep 6 04:24:16 PDT 2009 Simon Marlow <marlowsd(a)gmail.com> * Use -package-id rather than -package with GHC 6.11+ Ignore-this: a9cb1e8684411ea3fa04e0d54826f76b M ./Distribution/Simple/GHC.hs -3 +12 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090906112416-12142-148551b2…

1 0

patch applied (cabal): Install dyn way hi files
by Duncan Coutts 08 Sep '09

08 Sep '09

Tue Sep 8 07:28:53 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Install dyn way hi files Ignore-this: 9de867381e500fda321a29e137e71414 M ./Distribution/Simple/GHC.hs +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090908142853-adfee-8454397a…

1 0