- cabal-devel - Haskell.org

Cabal 2.0
by Duncan Coutts 17 Jan '09

17 Jan '09

All, I've started a wiki page to collect ideas for Cabal 2 http://hackage.haskell.org/trac/hackage/wiki/Cabal-2 The basic idea for Cabal 2 is to learn lessons from our how the existing design has fared and how we can make a better design to tackle an expanded set of goals. I'd like the page to be about suggested design concepts. I don't want to fill it with "wouldn't it be nice if we had a feature to help me doing ..." I guess it would also be useful to make links on that page to some of the discussions we've had on various lists, eg on the ghc users and libraries mailing lists where various people have made criticisms of the current design and suggested alternatives and improvements. Duncan

1 0

darcs patch: Fallback onto simpleHTTP when Network.Browser fails
by Stephen Hicks 17 Jan '09

17 Jan '09

Sat Oct 11 11:45:25 EDT 2008 Stephen Hicks <sdh33(a)cornell.edu> * Fallback onto simpleHTTP when Network.Browser fails

2 4

Technical Discussion of Cabal Improvements
by Curt Sampson 17 Jan '09

17 Jan '09

I've not noticed anything but PR and commit traffic on this list in the past couple of weeks; is it also the place to have discussions about (possibly radical) improvements to Cabal? For example, automatic generation of lists of dependent packages and so on? cjs -- Curt Sampson <cjs(a)starling-software.com> +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

2 1

[Hackage] #459: Find out what we can learn from SCons
by Hackage 17 Jan '09

17 Jan '09

#459: Find out what we can learn from SCons ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- [http://www.scons.org/ SCons] is a build system for various languages. This task is to do some research to compare SCons to the build component in Cabal and find out what lessons we can learn from SCons. The findings should be recorded on the [wiki:SCons] wiki page. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/459> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

patch applied (cabal-install): Only print the config file location for the global --help
by Duncan Coutts 16 Jan '09

16 Jan '09

Fri Jan 16 09:59:00 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Only print the config file location for the global --help M ./Main.hs -3 +6 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090116175900-adfee-…

1 0

[Hackage] #399: More information in the Paths_pkg.hs module, or a new module
by Hackage 16 Jan '09

16 Jan '09

#399: More information in the Paths_pkg.hs module, or a new module ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- There is more information about the system or about the package or configuration that we could include into a generated module. For example: * OS name (from standard enum names, not System.Info.os) * Arch name (similarly) * Compiler used for build * Package version (perhaps moved out of the `Paths_` module) * Other .cabal file package details (as Strings) * `x-foo` extension fields * license enum * authors, copyright * synopsis / description * home page, bug report url * configuration flag values * System details * big or little endian * Revision control context * git hash * darcs context -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/399> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #401: better support for multi-valued configuration flags
by Hackage 16 Jan '09

16 Jan '09

#401: better support for multi-valued configuration flags ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- For some packages one has to pick one of several mutually exclusive options. For example `yi` has a number of console or gui front ends. That can be expressed in terms of boolean flags but it's a little clumsy. We should consider adding some syntactic sugar. Currently it can be expressed by excluding the choice of picking none: {{{ if flag(gtk) ... if flag(vty) ... if flag(coca) && os(osx) ... if ! ( flag(gtk) || flag(vty) || (flag(coca) && os(osx)) ) buildable: false }}} That doesn't exclude the possibility of picking two options of course. In some cases we would want the options to be mutually exclusive and in others we would want to simply force the choice of one option, but multiple options might be possible. So the question is what kind of syntactic sugar would we like, how would it translate and how would it be exposed to package managers. eg: {{{ flag gui values: gtk, vty, coca if flag(gui==gtk) ... etc }}} and it'd translate into boolean choices that forced a choice of one flag being true and the others false. Needs some thought. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/401> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #400: fail and warnings for build configurations
by Hackage 16 Jan '09

16 Jan '09

#400: fail and warnings for build configurations ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- People expect `buildable: False` to fail the current configuration (rather than letting it configure and then not working at build time). But perhaps we should make that more explicit and allow a message, eg instead of: {{{ if os(windows) buildable: False }}} allow {{{ if os(windows) fail: it doesn't work on windows because, blah blah blah }}} And similarly we might want to warn users about selecting particular configurations eg: {{{ if flag(http) ... else warn: no http implementation selected, only local operations will be possible. You probably really want some http implementation. }}} The semantics roughly is that it's a workable but sub-optimal configuration. The solver should try to avoid warnings, by selecting another alternative. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/400> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #438: Cabal should warn or fail if user specifies a bad configuration flag
by Hackage 16 Jan '09

16 Jan '09

#438: Cabal should warn or fail if user specifies a bad configuration flag ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ----------------------------+----------------------------------------------- Let us take the example of Yi. Yi specifies a flag: {{{ flag ghcAPI Description: Enable linking with GHC API for advanced features. Default: False }}} The advanced features are nice indeed, and I wish to use them. So I configure thusly: {{{ gwern@craft:33763~/bin/yi>runhaskell Setup configure --user -fghc-api Configuring yi-0.5.3... }}} (Or perhaps I specify -fghcapi, or -fghc-API. There are a lot of quite reasonable permutations, and I suspect I have made every one of them over the past few months.) The point is, the flag is *wrong*. Completely wrong. If we turn on --verbose, we notice that {{{ Flags chosen: testing=True, hacking=False, cocoa=False, pango=False, gtk=False, vty=True, ghcapi=False }}} The user is not going to get what she requested. Worse, the user has no idea! Everything looks dandy! There is not the slightest indication that something bad has happened. Half an hour later when Yi has compiled and installed, any user trying to use the Shim.* modules in their yi.hs is in for an unpleasant surprise. So the basic point here is: if the user specifies a flag, and the flag doesn't match any flags in the cabal file, *something* is wrong. Either the cabal file is damaged in someway, or the user mistyped. I think an error would be perfectly reasonable here, in the same way that missing fields is a reasonable reason for erroring out; but at a minimum a warning is warranted. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/438> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #432: cabal-install patches for HTTP 4000.0.0
by Hackage 16 Jan '09

16 Jan '09

#432: cabal-install patches for HTTP 4000.0.0 ---------------------------------+------------------------------------------ Reporter: Bart Massey | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ I noticed that the constraints on the packages for cabal-install required some pretty old stuff. Rather than go there, I decided to loosen the constraints and see what happened. The current version of Cabal (1.7) and zlib (0.5.0.0) seem to work fine. Some patches were required to get current HTTP (4000.0.0) to work. I attach these patches in case anyone cares. I have done no testing of these patches other than trying a few simple cabal commands. They seemed to work. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/432> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2