- cabal-devel - Haskell.org

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

19 Dec '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: easy (<4 hours) Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by duncan): * difficulty: normal => easy (<4 hours) Comment: Feature included in Cabal-1.8 release. Two bits remaining however: * Support for ghc-6.12 needs fixing. We currently get the installed package ids wrong. * Need to review and apply blackh's patches for cabal-install. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:18> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #171: Add command to automagically create an initial cabal package
by Hackage 19 Dec '09

19 Dec '09

#171: Add command to automagically create an initial cabal package --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Linux | --------------------------+------------------------------------------------- Don Stewart has a nice tool called mkcabal (http://www.cse.unsw.edu.au/~dons/code/mkcabal/) which creates an initial cabal package. It would be nice to have this built into the 'cabal' program itself so that "cabal create" or "cabal init" or similar would interactively create a cabal package. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/171> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

[Hackage] #516: Maintain central haddock module index.
by Hackage 19 Dec '09

19 Dec '09

#516: Maintain central haddock module index. ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- The ghc api documentation includes a central index of [http://haskell.org/ghc/docs/latest/html/libraries/ all the modules in the core libraries]. Some people would like the same for all the modules provided by all the packages they have installed. See #206 for some of the previous discussion on this topic. The questions to resolve are where the index should be kept by default and how it should be configured (eg switched off). For example for a per-user install an index could live in `$HOME/.cabal/share/doc/index.html` but the equivalent is not appropriate for other prefixes like `/usr/local`. For global packages shipped by a distro the problem is much worse. We do not really want to have to have distro packages re-generating an html index every time they add and remove a package. Perhaps we should be looking at alternative solutions like using [http://live.gnome.org/devhelp devhelp] which can give easy access to installed documentation without maintaining a central index/catalog. Similar issues apply to a hoogle index. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/516> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #484: generalise version range syntax
by Hackage 18 Dec '09

18 Dec '09

#484: generalise version range syntax ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- The internal version range syntax allows arbitrary unions and intersections. The parser only allows two clauses and no brackets. See: http://haskell.org/pipermail/haskell-cafe/2009-January/054049.html {{{ I'm having some difficulty specifying dependencies in my .cabal file for a package I'm looking to upload to hackage soon. The difficulty is as follows. I basically want to specify parsec (>= 2.1 && < 3.0.0) || (> 3.0.0 && < 4) }}} I suggest we allow any number of clauses and brackets, to match the internal representation. We could also add `/=` or `!=` syntax since that is also easy to represent. It is harder to translate into other representations however we have a new view in terms of version ranges which should make it easier to do translations and to discover when the version range has more detail than can be represented in the target language (and maybe even approximate in such situations). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/484> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #485: preference on base version should only be applied for open constraints
by Hackage 18 Dec '09

18 Dec '09

#485: preference on base version should only be applied for open constraints ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Currently we apply the preference on the base version. That means that if you have base 3 and 4 available then for dependencies like: {{{ build-depends: base >= 2 }}} or {{{ build-depends: base >= 3 && < 5 }}} Then we end up picking base 3. That makes perfect sense in the first case. In the first case the developer clearly did not think about base 4. However in the second case they clearly have thought about it and yet we end up picking base 3. On balance it is probably better to pick base 4 in the second case even though both are allowed. One suggestion for how to handle soft constraints on the version of base is to say that we only apply the preference if the version is not bounded above. If it is bounded above then we use no preference and end up picking the highest version available. This policy cannot be expressed in the simple preferred versions syntax. It's probably ok to hard code it for base for now. This will require generalising the interface to the constraint solver to supply preferences in a slightly different form. It may need to be as a function from a list of possible versions to the selected version. The function would also be supplied with the package it's for, the dependency and the list of installed versions since it may want to take any of these into account and it is needed to express the above policy. This is related to the splitting of preferences into real preferences and hacks (see #483). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/485> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

patch applied (cabal): Make lack of language extensions an error not a warning
by Duncan Coutts 16 Dec '09

16 Dec '09

Wed Dec 16 12:45:05 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Make lack of language extensions an error not a warning Also improve the error message somewhat M ./Distribution/Simple/Configure.hs -3 +5 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20091216204505-adfee-ce68c746…

1 0

patch applied (cabal): Specify DOCTYPE when generating userguide html
by Duncan Coutts 16 Dec '09

16 Dec '09

Tue Dec 15 19:53:21 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Specify DOCTYPE when generating userguide html Ignore-this: 9d3b09e3c593a8d5f39b691ef2ceb377 Useless docbook tools. M ./Makefile +6 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20091216035321-adfee-245fc526…

1 0

patch applied (cabal): Registering packages needs all the package dbs listed
by Duncan Coutts 16 Dec '09

16 Dec '09

Fri Dec 11 05:32:33 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Registering packages needs all the package dbs listed Ignore-this: 249cc7ae1452bfa8e970f0ba24d4ff5f Important for the case of registering inplace when we're using a specific package db, e.g. when doing isolated builds. M ./Distribution/Simple/Build.hs -1 +2 M ./Distribution/Simple/Compiler.hs -1 +1 M ./Distribution/Simple/GHC.hs -9 +9 M ./Distribution/Simple/Program/HcPkg.hs -9 +23 M ./Distribution/Simple/Register.hs -21 +21 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20091211133233-adfee-1a83cc15…

1 0

patch applied (cabal): Switch a few distribution checks to build warnings
by Duncan Coutts 16 Dec '09

16 Dec '09

Wed Dec 2 06:35:49 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Switch a few distribution checks to build warnings Ignore-this: bbadf449113d009b51837bc1dd3488af In particular the one about -prof since this leads to borked packages. M ./Distribution/PackageDescription/Check.hs -7 +9 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20091202143549-adfee-21dd681f…

1 0

Re: [Haskell-cafe] changelogs for packages on Hackage
by Duncan Coutts 16 Dec '09

16 Dec '09

On Wed, 2009-12-16 at 11:18 +0200, Valery V. Vorotyntsev wrote: > It would be nice if Hackage displayed ``recent changes'' of a package. > [severity: wishlist] > > You see, I am subscribed to the ``hackage - recent additions'' feed > [http://hackage.haskell.org/packages/archive/recent.rss] and receive > entries that look like this: > > Cabal 1.8.0.2 > Added by DuncanCoutts, Wed Dec 16 04:19:24 UTC 2009. > A framework for packaging Haskell software > > This is sweet. But how can I tell what's new in Cabal since 1.6.0.3? > (`Cabal' is just an example here.) Yep it's a fair point. http://hackage.haskell.org/trac/hackage/ticket/299 Some packages have a changelog file in them that we could display, though most don't. For those that do have a changelog, how we avoid displaying all of history is a bit tricky. For those that do not, ideally we could derive a changelog by looking at the difference in the API. The latter requires a tool we've not written yet. Duncan

1 0