From ross at soi.city.ac.uk Sat Sep 1 10:10:32 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Sep 1 10:01:12 2007 Subject: patch applied (cabal): Maintainer is now cabal-devel@haskell.org Message-ID: <20070901141032.GA31286@cvs.haskell.org> Sat Sep 1 07:09:21 PDT 2007 Ross Paterson * Maintainer is now cabal-devel@haskell.org M ./Cabal.cabal -1 +1 From duncan.coutts at worc.ox.ac.uk Sat Sep 1 13:32:06 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Sep 1 13:22:48 2007 Subject: patch applied (cabal): Don't use normalise when parsing configure arguments Message-ID: <20070901173206.GA2448@cvs.haskell.org> Sat Sep 1 09:20:43 PDT 2007 Duncan Coutts * Don't use normalise when parsing configure arguments M ./Distribution/Simple/Setup.hs -4 +3 From duncan.coutts at worc.ox.ac.uk Sat Sep 1 13:32:09 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Sep 1 13:22:51 2007 Subject: patch applied (cabal): Pass --configure-option= options to configure in the right order Message-ID: <20070901173209.GA2483@cvs.haskell.org> Sat Sep 1 10:31:47 PDT 2007 Duncan Coutts * Pass --configure-option= options to configure in the right order in the same order as they were passed to cabal configure on the command line M ./Distribution/Simple/Setup.hs -1 +1 From duncan.coutts at worc.ox.ac.uk Sat Sep 1 13:32:08 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Sep 1 13:22:51 2007 Subject: patch applied (cabal): Add --prog-arg= and make --prog-args parse quotes Message-ID: <20070901173208.GA2469@cvs.haskell.org> Sat Sep 1 10:17:42 PDT 2007 Duncan Coutts * Add --prog-arg= and make --prog-args parse quotes So this provides two ways of passing options that contain embeded spaces: --foo-args='--bar --baz="path with spaces in"' --foo-arg=--bar --foo-arg=--baz="path with spaces in" all args passed this way are collected in order. M ./Distribution/Simple/Setup.hs -27 +59 M ./doc/Cabal.xml -1 +28 From ross at soi.city.ac.uk Sat Sep 1 13:41:58 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Sep 1 13:32:44 2007 Subject: patch applied (cabal): Pass --configure-option= options to configure in the right order In-Reply-To: <20070901173209.GA2483@cvs.haskell.org> References: <20070901173209.GA2483@cvs.haskell.org> Message-ID: <20070901174158.GA4204@soi.city.ac.uk> On Sat, Sep 01, 2007 at 10:32:09AM -0700, Duncan Coutts wrote: > Sat Sep 1 10:31:47 PDT 2007 Duncan Coutts > * Pass --configure-option= options to configure in the right order > in the same order as they were passed to cabal configure on the command line Can we standardize on either -arg or -option (I don't care which)? From trac at galois.com Sat Sep 1 19:23:12 2007 From: trac at galois.com (Hackage) Date: Sat Sep 1 19:13:51 2007 Subject: [Hackage] #7: add --ghc-args and such to configure In-Reply-To: <054.0cbbc2f661180e00c5e12d92edae7bad@localhost> References: <054.0cbbc2f661180e00c5e12d92edae7bad@localhost> Message-ID: <063.6e998fc056a531eb4a99c05d31d3b284@localhost> #7: add --ghc-args and such to configure ----------------------------------+----------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: closed Priority: high | Milestone: Cabal-1.2 Component: Cabal | Version: 1.1.3 Severity: normal | Resolution: fixed Keywords: | Ghcversion: 6.2.1 Difficulty: very easy (<1 hour) | Platform: Linux ----------------------------------+----------------------------------------- Changes (by duncan): * resolution: => fixed * status: reopened => closed Comment: Now documented. Also, I've added a {{{--prog-arg=}}} flag that behaves like {{{--configure-option=}}}. I've also made {{{--prog-args=}}} parse it's args more cleverly. Instead of using words which breaks on files with embedded spaces we now use a slightly more clever lexer that allows simple quoting with "" chars. eg: {{{ splitArgs "--foo=\"C:\Program Files\Bar\" --baz" = ["--foo=C:\Program Files\Bar", "--baz"] }}} so on the command line you'd use: {{{ ./setup configure --foo-args='--bar="some path with spaces"' }}} That is the " chars have to be passed to setup, so if necessary they have to be escaped in the shell invocation. The alternative of course is to use {{{ ./setup configure --foo-arg=--bar="some path with spaces" }}} again, assuming your shell parses {{{--foo-arg=--bar="some path with spaces"}}} into a single argument {{{--foo-arg=--bar=some path with spaces}}}. Oh the joys of shell quoting. -- Ticket URL: Hackage My example project From duncan.coutts at worc.ox.ac.uk Sat Sep 1 19:52:31 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Sep 1 19:41:10 2007 Subject: patch applied (packages/regex-posix): Make setup script compile again after recent Cabal changes In-Reply-To: <200709011940.41943.sven.panne@aedion.de> References: <20070901115604.GA28949@cvs.haskell.org> <1188668278.10322.180.camel@localhost> <200709011940.41943.sven.panne@aedion.de> Message-ID: <1188690751.10322.189.camel@localhost> On Sat, 2007-09-01 at 19:40 +0200, Sven Panne wrote: > On Saturday 01 September 2007 19:37, Duncan Coutts wrote: > > On Sat, 2007-09-01 at 04:56 -0700, Sven Panne wrote: > > > Sat Sep 1 04:55:36 PDT 2007 sven.panne@aedion.de > > > * Make setup script compile again after recent Cabal changes > > > > BTW, as far as I can see, this Setup.hs is no longer needed. If it read > > it correctly, all it does is implement a --ghc-option= flag. Cabal now > > does that itself --ghc-args= or --ghc=arg= > > I've just copied the Setup.lhs from regex-base, because that worked (and I am > currently not interested in the Cabal-API-of-the-day). Indeed, I recommend not putting any custom code in Setup.(l)hs unless it's absolutely essential. If we want to keep making improvements to Cabal's internal code and adding features we will inevitably have to continue making changes to the hooks api and other internal apis. At the moment the design of the hooks api is very fragile. Any change breaks all Setup.lhs programs. We've don't yet really know what the hooks api should look like, but we expect there will be some significant change in the next version. Hopefully we can come up with a design that is less fragile, for example using a Configure/Build monad rather than passing in lots of information a separate arguments, so that we could add more information without breaking existing hooks users. On the other hand we can make much stronger stability guarantees about the .cabal file format. > So probably all regex-*/Setup.lhs could be nuked... Or at least replaced with the default one that never breaks. Duncan From duncan.coutts at worc.ox.ac.uk Sat Sep 1 20:00:51 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Sep 1 19:49:30 2007 Subject: [Haskell-cafe] RE: Definition of the Haskell standard library In-Reply-To: <200709011847.16725.sven.panne@aedion.de> References: <1185903596.5989.46.camel@localhost> <200709011847.16725.sven.panne@aedion.de> Message-ID: <1188691251.10322.198.camel@localhost> On Sat, 2007-09-01 at 18:47 +0200, Sven Panne wrote: > On Tuesday 31 July 2007 19:39, Duncan Coutts wrote: > > [...] > > The docs for those packages would be available for packages installed > > via cabal (assuming the user did the optional haddock step) and would > > link to each other. > > Well, on a normal Linux distro a user should *never* have to call cabal (or > any of its cousins) directly, the distro's package manager should be the used > instead. On an e.g. RPM system, the .spec file would use Cabal to e.g. > (un-)register a package, because RPM has to know what is installed, which > other packages are prerequisites, how to cleanly uninstall, etc. IMHO Cabal > should not try to mirror a full-fledged package system, simply because on > every (non-Windows ;-) platform there are tons of native tools for this > purpose, and Cabal is not "in the driver's seat" when it comes to SW > installation. I think it's inevitable that there will always be a mixture of packages that are managed by the system package manager and ones that are too insignificant to be packaged by the distro. So cabal-install should cooperate with the system package manager somehow. Another strategy would be to have tools that the users can use to generate system packages from cabal packages and then install those via the system package manager. We already have such tools for rpm and gentoo ebuilds. Again, these would be for the case of less significant package that the distro does not package itself. For example, gentoo has a tool that can be used to install perl CPAN packages via the system package manager, since there are many 1000's of CPAN packages and only a few hundred of those are included in the main portage collection. There are other cases not covered by system package managers, like unprivileged user installations under $HOME. > > The problem with generating one of those is what manages it? What > > package would it belong to etc. > > Of course we are not the first project to face this kind of problem: Texinfo > offers a central contents page as well. To maintain this page, it comes with [..] > A "install-haddock" tool would be the solution IMHO. That re-generates the index page, right. Perhaps haddock itself should be extended with this ability. All it should need to do is read all the .haddock files that ghc-pkg knows about and generate the index page from that. I assume the .haddock files contain enough information to do this, or it could be modified to include enough. Duncan From duncan.coutts at worc.ox.ac.uk Sat Sep 1 20:08:01 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Sep 1 19:56:39 2007 Subject: patch applied (cabal): Pass --configure-option= options to configure in the right order In-Reply-To: <20070901174158.GA4204@soi.city.ac.uk> References: <20070901173209.GA2483@cvs.haskell.org> <20070901174158.GA4204@soi.city.ac.uk> Message-ID: <1188691681.10322.202.camel@localhost> On Sat, 2007-09-01 at 18:41 +0100, Ross Paterson wrote: > On Sat, Sep 01, 2007 at 10:32:09AM -0700, Duncan Coutts wrote: > > Sat Sep 1 10:31:47 PDT 2007 Duncan Coutts > > * Pass --configure-option= options to configure in the right order > > in the same order as they were passed to cabal configure on the command line > > Can we standardize on either -arg or -option (I don't care which)? Yep, let's change --configure-option to --configure-arg, --configure-option is new in Cabal-1.1.7 and we've had --foo-args= flags before so that's the better established convention I think. Duncan From duncan.coutts at worc.ox.ac.uk Sat Sep 1 20:33:26 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Sep 1 20:24:04 2007 Subject: patch applied (cabal): Change --configure-option= to --configure-arg= Message-ID: <20070902003326.GA8992@cvs.haskell.org> Sat Sep 1 17:33:34 PDT 2007 Duncan Coutts * Change --configure-option= to --configure-arg= For consitency with other flags. M ./Distribution/Simple/Setup.hs -3 +3 M ./doc/Cabal.xml -2 +2 From ross at soi.city.ac.uk Sat Sep 1 20:53:44 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Sep 1 20:44:37 2007 Subject: patch applied (cabal): Change --configure-option= to --configure-arg= In-Reply-To: <20070902003326.GA8992@cvs.haskell.org> References: <20070902003326.GA8992@cvs.haskell.org> Message-ID: <20070902005344.GA6725@soi.city.ac.uk> On Sat, Sep 01, 2007 at 05:33:26PM -0700, Duncan Coutts wrote: > Sat Sep 1 17:33:34 PDT 2007 Duncan Coutts > * Change --configure-option= to --configure-arg= > For consitency with other flags. Also --ghc-option for build and makefile. These are used by GHC only; I wonder if the configure option would be a substitute. I forgot that the file format includes XXX-options fields, which might be a source of confusion. From duncan.coutts at worc.ox.ac.uk Sun Sep 2 08:56:45 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Sep 2 08:45:22 2007 Subject: patch applied (cabal): Change --configure-option= to --configure-arg= In-Reply-To: <20070902005344.GA6725@soi.city.ac.uk> References: <20070902003326.GA8992@cvs.haskell.org> <20070902005344.GA6725@soi.city.ac.uk> Message-ID: <1188737805.10322.228.camel@localhost> On Sun, 2007-09-02 at 01:53 +0100, Ross Paterson wrote: > On Sat, Sep 01, 2007 at 05:33:26PM -0700, Duncan Coutts wrote: > > Sat Sep 1 17:33:34 PDT 2007 Duncan Coutts > > * Change --configure-option= to --configure-arg= > > For consitency with other flags. > > Also --ghc-option for build and makefile. These are used by GHC only; > I wonder if the configure option would be a substitute. Or configure's --ghc-arg flag. I'll ask Ian if we still need those build/makefile --ghc-option flags. > I forgot that the file format includes XXX-options fields, which might > be a source of confusion. Mm, good point. We can't change those of course. What do you think we should do? Duncan From ross at soi.city.ac.uk Sun Sep 2 09:09:43 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Sep 2 09:00:35 2007 Subject: patch applied (cabal): Change --configure-option= to --configure-arg= In-Reply-To: <1188737805.10322.228.camel@localhost> References: <20070902003326.GA8992@cvs.haskell.org> <20070902005344.GA6725@soi.city.ac.uk> <1188737805.10322.228.camel@localhost> Message-ID: <20070902130943.GA23733@soi.city.ac.uk> On Sun, Sep 02, 2007 at 01:56:45PM +0100, Duncan Coutts wrote: > On Sun, 2007-09-02 at 01:53 +0100, Ross Paterson wrote: > > On Sat, Sep 01, 2007 at 05:33:26PM -0700, Duncan Coutts wrote: > > > Sat Sep 1 17:33:34 PDT 2007 Duncan Coutts > > > * Change --configure-option= to --configure-arg= > > > For consitency with other flags. > > > > Also --ghc-option for build and makefile. These are used by GHC only; > > I wonder if the configure option would be a substitute. > > Or configure's --ghc-arg flag. I'll ask Ian if we still need those > build/makefile --ghc-option flags. Sorry, that's what I meant. > > I forgot that the file format includes XXX-options fields, which might > > be a source of confusion. > > Mm, good point. We can't change those of course. What do you think we > should do? I think it argues for --PROG-option(s). The -args options weren't documented, so they didn't exist. From duncan.coutts at worc.ox.ac.uk Sun Sep 2 09:38:43 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Sep 2 09:27:19 2007 Subject: patch applied (cabal): Change --configure-option= to --configure-arg= In-Reply-To: <20070902130943.GA23733@soi.city.ac.uk> References: <20070902003326.GA8992@cvs.haskell.org> <20070902005344.GA6725@soi.city.ac.uk> <1188737805.10322.228.camel@localhost> <20070902130943.GA23733@soi.city.ac.uk> Message-ID: <1188740323.10322.229.camel@localhost> On Sun, 2007-09-02 at 14:09 +0100, Ross Paterson wrote: > > > I forgot that the file format includes XXX-options fields, which might > > > be a source of confusion. > > > > Mm, good point. We can't change those of course. What do you think we > > should do? > > I think it argues for --PROG-option(s). The -args options weren't > documented, so they didn't exist. Right. Duncan From igloo at earth.li Sun Sep 2 15:40:57 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Sep 2 15:31:32 2007 Subject: patch applied (cabal): Suppress some warnings Message-ID: <20070902194057.GA29300@cvs.haskell.org> Sun Sep 2 12:39:55 PDT 2007 Ian Lynagh * Suppress some warnings M ./Distribution/Simple/Install.hs +7 From igloo at earth.li Sun Sep 2 18:53:22 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Sep 2 18:43:58 2007 Subject: patch applied (cabal): Warning supression for Windows Message-ID: <20070902225322.GA32487@cvs.haskell.org> Sun Sep 2 15:51:11 PDT 2007 Ian Lynagh * Warning supression for Windows M ./Distribution/Simple/InstallDirs.hs +7 From duncan.coutts at worc.ox.ac.uk Sun Sep 2 19:24:39 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Sep 2 19:15:16 2007 Subject: patch applied (cabal): Change --configure-option= to --configure-arg= Message-ID: <20070902232439.GA1756@cvs.haskell.org> Sat Sep 1 17:33:34 PDT 2007 Duncan Coutts UNDO: Change --configure-option= to --configure-arg= For consitency with other flags. M ./Distribution/Simple/Setup.hs -3 +3 M ./doc/Cabal.xml -2 +2 From duncan.coutts at worc.ox.ac.uk Sun Sep 2 19:24:41 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Sep 2 19:15:16 2007 Subject: patch applied (cabal): Rename --prog-args to --prog-options Message-ID: <20070902232441.GA1776@cvs.haskell.org> Sun Sep 2 10:06:37 PDT 2007 Duncan Coutts * Rename --prog-args to --prog-options amd --prog-arg to --prog-arg and update the user guide. M ./Distribution/Simple/Setup.hs -17 +18 M ./doc/Cabal.xml -14 +15 From duncan.coutts at worc.ox.ac.uk Mon Sep 3 07:44:01 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 3 07:34:34 2007 Subject: patch applied (cabal): Remove register --with-hc-pkg flag Message-ID: <20070903114401.GA16671@cvs.haskell.org> Mon Sep 3 02:10:38 PDT 2007 Duncan Coutts * Remove register --with-hc-pkg flag It was just a hack for the benefit of ghc and we don't need it now. M ./Distribution/Simple/Setup.hs -10 +3 M ./doc/Cabal.xml -10 From duncan.coutts at worc.ox.ac.uk Mon Sep 3 07:44:02 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 3 07:34:36 2007 Subject: patch applied (cabal): Make userSpecifyArgs update the args even if the prog is configured already Message-ID: <20070903114402.GA16691@cvs.haskell.org> Mon Sep 3 03:48:52 PDT 2007 Duncan Coutts * Make userSpecifyArgs update the args even if the prog is configured already M ./Distribution/Simple/Program.hs -2 +7 From duncan.coutts at worc.ox.ac.uk Mon Sep 3 07:44:04 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 3 07:34:37 2007 Subject: patch applied (cabal): Generalise build --ghc-option flag to --prog-option for any prog Message-ID: <20070903114404.GA16705@cvs.haskell.org> Mon Sep 3 04:06:58 PDT 2007 Duncan Coutts * Generalise build --ghc-option flag to --prog-option for any prog and remove makefile --ghc-option flag as it's not used (as far as I can see). It works generically by updating the ProgramConfiguration rather than the previous ad-hoc implementation. This feature is generally only useful for hackers who want to pass extra args to a progam during the build step (probably as a one-off) without having to reconfigure. M ./Distribution/Simple.hs -4 +8 M ./Distribution/Simple/Build.hs -7 +3 M ./Distribution/Simple/Setup.hs -47 +52 M ./doc/Cabal.xml -18 +15 From duncan.coutts at worc.ox.ac.uk Mon Sep 3 07:44:05 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 3 07:34:38 2007 Subject: patch applied (cabal): Fix haddock markup Message-ID: <20070903114405.GA16719@cvs.haskell.org> Mon Sep 3 04:31:45 PDT 2007 Duncan Coutts * Fix haddock markup Thanks to int-e for reporting M ./Distribution/Simple/LocalBuildInfo.hs -2 +2 From duncan.coutts at worc.ox.ac.uk Mon Sep 3 08:23:51 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 3 08:14:24 2007 Subject: patch applied (cabal): Oops, fix Distribution.Make Message-ID: <20070903122351.GA17635@cvs.haskell.org> Mon Sep 3 05:23:55 PDT 2007 Duncan Coutts * Oops, fix Distribution.Make M ./Distribution/Make.hs -1 +3 From duncan.coutts at worc.ox.ac.uk Mon Sep 3 08:23:52 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 3 08:14:27 2007 Subject: patch applied (cabal): Remove unused helper function Message-ID: <20070903122352.GA17656@cvs.haskell.org> Mon Sep 3 05:24:08 PDT 2007 Duncan Coutts * Remove unused helper function Ok to remove, it never appeared in any release. M ./Distribution/PackageDescription.hs -11 From duncan.coutts at worc.ox.ac.uk Mon Sep 3 08:47:15 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 3 08:35:47 2007 Subject: Cabal branched for a 1.2 release Message-ID: <1188823635.10322.266.camel@localhost> Just to let everyone know, I've branched Cabal for a 1.2 release. Cabal 1.2 branch: http://darcs.haskell.org/cabal-branches/cabal-1.2/ Cabal HEAD branch: http://darcs.haskell.org/cabal/ The version number in the 1.2 branch is still 1.1.7, we'll make a 1.2.0 release from this branch soon. The intention is that GHC 6.8.1 RC will use Cabal 1.2 Duncan From duncan.coutts at worc.ox.ac.uk Wed Sep 5 18:42:53 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Sep 5 18:33:21 2007 Subject: patch applied (cabal): Rewrite the parser for the configuration structure to allow laout or braces Message-ID: <20070905224253.GA7958@cvs.haskell.org> Wed Sep 5 15:36:09 PDT 2007 Duncan Coutts * Rewrite the parser for the configuration structure to allow laout or braces Joint work with Thomas Schilling. The sections and indeed fields (and if/else) can now use either explicit brace {} style layout or indentation eg: > library > exposed-modules: Blah or > library { > exposed-modules: > } layout style can be nested within explict braces style and vica versa. Also add some more checks and relax the tab checks. Unrecognised sections, like unrecognised fields, are not fatal errors, so we could add sections in future without breaking old cabal. M ./Distribution/PackageDescription.hs -68 +45 M ./Distribution/ParseUtils.hs -160 +255 From duncan.coutts at worc.ox.ac.uk Wed Sep 5 18:46:45 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Sep 5 18:37:12 2007 Subject: patch applied (cabal-branches/cabal-1.2): Rewrite the parser for the configuration structure to allow laout or braces Message-ID: <20070905224645.GA8065@cvs.haskell.org> Wed Sep 5 15:36:09 PDT 2007 Duncan Coutts * Rewrite the parser for the configuration structure to allow laout or braces Joint work with Thomas Schilling. The sections and indeed fields (and if/else) can now use either explicit brace {} style layout or indentation eg: > library > exposed-modules: Blah or > library { > exposed-modules: > } layout style can be nested within explict braces style and vica versa. Also add some more checks and relax the tab checks. Unrecognised sections, like unrecognised fields, are not fatal errors, so we could add sections in future without breaking old cabal. M ./Distribution/PackageDescription.hs -68 +45 M ./Distribution/ParseUtils.hs -160 +255 From duncan.coutts at worc.ox.ac.uk Wed Sep 5 18:46:48 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Sep 5 18:37:13 2007 Subject: patch applied (cabal-branches/cabal-1.2): make this buildable with GHC 6.2.x Message-ID: <20070905224648.GA8086@cvs.haskell.org> Mon Sep 3 07:02:32 PDT 2007 Simon Marlow * make this buildable with GHC 6.2.x M ./Distribution/Compat/Map.hs -1 +2 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:44 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:08 2007 Subject: patch applied (cabal-branches/cabal-1.2): Update authors list in LICENSE and remove duplicate copyright file Message-ID: <20070906123644.GA25212@cvs.haskell.org> Wed Sep 5 17:22:35 PDT 2007 Duncan Coutts * Update authors list in LICENSE and remove duplicate copyright file We currently have 39 different authors, all those with a significant number of patches are listed as copyright holders in the LICENSE file. M ./LICENSE -1 +4 R ./copyright From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:46 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:09 2007 Subject: patch applied (cabal): Update authors list in LICENSE and remove duplicate copyright file Message-ID: <20070906123646.GA25226@cvs.haskell.org> Wed Sep 5 17:22:35 PDT 2007 Duncan Coutts * Update authors list in LICENSE and remove duplicate copyright file We currently have 39 different authors, all those with a significant number of patches are listed as copyright holders in the LICENSE file. M ./LICENSE -1 +4 R ./copyright From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:46 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:10 2007 Subject: patch applied (cabal-branches/cabal-1.2): Update changelog Message-ID: <20070906123646.GA25240@cvs.haskell.org> Wed Sep 5 17:25:39 PDT 2007 Duncan Coutts * Update changelog M ./changelog +35 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:47 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:11 2007 Subject: patch applied (cabal): Update changelog Message-ID: <20070906123647.GA25254@cvs.haskell.org> Wed Sep 5 17:25:39 PDT 2007 Duncan Coutts * Update changelog M ./changelog +35 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:47 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:12 2007 Subject: patch applied (cabal-branches/cabal-1.2): Use layout rather than braces {} for sections in our own .cabal file Message-ID: <20070906123647.GA25268@cvs.haskell.org> Wed Sep 5 17:28:44 PDT 2007 Duncan Coutts * Use layout rather than braces {} for sections in our own .cabal file Since we can and we want to set a good example. M ./Cabal.cabal -10 +4 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:49 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:12 2007 Subject: patch applied (cabal): Use layout rather than braces {} for sections in our own .cabal file Message-ID: <20070906123649.GA25282@cvs.haskell.org> Wed Sep 5 17:28:44 PDT 2007 Duncan Coutts * Use layout rather than braces {} for sections in our own .cabal file Since we can and we want to set a good example. M ./Cabal.cabal -10 +4 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:49 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:13 2007 Subject: patch applied (cabal-branches/cabal-1.2): Fix haddock markup Message-ID: <20070906123649.GA25296@cvs.haskell.org> Wed Sep 5 18:02:21 PDT 2007 Duncan Coutts * Fix haddock markup M ./Distribution/ParseUtils.hs -2 +3 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:50 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:15 2007 Subject: patch applied (cabal): Fix haddock markup Message-ID: <20070906123650.GA25310@cvs.haskell.org> Wed Sep 5 18:02:21 PDT 2007 Duncan Coutts * Fix haddock markup M ./Distribution/ParseUtils.hs -2 +3 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:50 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:15 2007 Subject: patch applied (cabal-branches/cabal-1.2): Bump version number to 1.2.0 Message-ID: <20070906123650.GA25324@cvs.haskell.org> Wed Sep 5 18:03:37 PDT 2007 Duncan Coutts * Bump version number to 1.2.0 M ./Cabal.cabal -3 +3 M ./Makefile -2 +2 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:51 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:16 2007 Subject: patch applied (cabal): Bump version number to 1.2.0 Message-ID: <20070906123651.GA25339@cvs.haskell.org> Wed Sep 5 18:03:37 PDT 2007 Duncan Coutts * Bump version number to 1.2.0 M ./Cabal.cabal -3 +3 M ./Makefile -2 +2 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:52 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:16 2007 Subject: patch applied (cabal-branches/cabal-1.2): note need to use -i when bootstrapping ghc, and update coders list Message-ID: <20070906123652.GA25353@cvs.haskell.org> Wed Sep 5 18:20:55 PDT 2007 Duncan Coutts * note need to use -i when bootstrapping ghc, and update coders list M ./README -2 +5 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:54 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:20 2007 Subject: patch applied (cabal-branches/cabal-1.2): Remove now-empty dependencies dir Message-ID: <20070906123654.GA25379@cvs.haskell.org> Wed Sep 5 18:21:44 PDT 2007 Duncan Coutts * Remove now-empty dependencies dir Not needed since cabal-install moved to another repo. R ./dependencies/ From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:53 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:20 2007 Subject: patch applied (cabal): note need to use -i when bootstrapping ghc, and update coders list Message-ID: <20070906123653.GA25369@cvs.haskell.org> Wed Sep 5 18:20:55 PDT 2007 Duncan Coutts * note need to use -i when bootstrapping ghc, and update coders list M ./README -2 +5 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:55 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:21 2007 Subject: patch applied (cabal): Remove now-empty dependencies dir Message-ID: <20070906123655.GA25401@cvs.haskell.org> Wed Sep 5 18:21:44 PDT 2007 Duncan Coutts * Remove now-empty dependencies dir Not needed since cabal-install moved to another repo. R ./dependencies/ From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:55 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:21 2007 Subject: patch applied (cabal-branches/cabal-1.2): TAG 1.2.0 Message-ID: <20070906123655.GA25414@cvs.haskell.org> Thu Sep 6 05:18:30 PDT 2007 Duncan Coutts tagged 1.2.0 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 08:36:57 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 08:27:21 2007 Subject: patch applied (cabal): TAG 1.2.0 Message-ID: <20070906123657.GA25440@cvs.haskell.org> Thu Sep 6 05:18:30 PDT 2007 Duncan Coutts tagged 1.2.0 From Malcolm.Wallace at cs.york.ac.uk Thu Sep 6 10:56:59 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Sep 6 10:47:22 2007 Subject: patch applied (cabal): nhc-options should be spelled nhc98-options Message-ID: <20070906145659.GA29917@cvs.haskell.org> Thu Sep 6 07:35:36 PDT 2007 Malcolm.Wallace@cs.york.ac.uk * nhc-options should be spelled nhc98-options M ./doc/Cabal.xml -2 +5 From Malcolm.Wallace at cs.york.ac.uk Thu Sep 6 10:57:01 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Sep 6 10:47:24 2007 Subject: patch applied (cabal): Fix various mispellings of nhc98. Message-ID: <20070906145701.GA29940@cvs.haskell.org> Thu Sep 6 07:39:59 PDT 2007 Malcolm.Wallace@cs.york.ac.uk * Fix various mispellings of nhc98. M ./Distribution/PackageDescription.hs -1 +1 M ./Distribution/Simple/NHC.hs -1 +1 M ./Distribution/Simple/Program.hs -1 +1 M ./Distribution/Simple/Setup.hs -3 +3 From Malcolm.Wallace at cs.york.ac.uk Thu Sep 6 10:57:26 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Sep 6 10:47:48 2007 Subject: patch applied (cabal-branches/cabal-1.2): nhc-options should be spelled nhc98-options Message-ID: <20070906145726.GA29977@cvs.haskell.org> Thu Sep 6 07:35:36 PDT 2007 Malcolm.Wallace@cs.york.ac.uk * nhc-options should be spelled nhc98-options M ./doc/Cabal.xml -2 +5 From Malcolm.Wallace at cs.york.ac.uk Thu Sep 6 10:57:27 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Sep 6 10:47:51 2007 Subject: patch applied (cabal-branches/cabal-1.2): Fix various mispellings of nhc98. Message-ID: <20070906145727.GA29991@cvs.haskell.org> Thu Sep 6 07:39:59 PDT 2007 Malcolm.Wallace@cs.york.ac.uk * Fix various mispellings of nhc98. M ./Distribution/PackageDescription.hs -1 +1 M ./Distribution/Simple/NHC.hs -1 +1 M ./Distribution/Simple/Program.hs -1 +1 M ./Distribution/Simple/Setup.hs -3 +3 From Malcolm.Wallace at cs.york.ac.uk Thu Sep 6 11:09:17 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Sep 6 10:59:40 2007 Subject: patch applied (cabal): spell nhc98-options correctly Message-ID: <20070906150917.GA30639@cvs.haskell.org> Thu Sep 6 08:04:11 PDT 2007 Malcolm.Wallace@cs.york.ac.uk * spell nhc98-options correctly M ./Cabal.cabal -1 +1 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 11:23:14 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 11:11:35 2007 Subject: Cabal repos and branches Message-ID: <1189092195.10322.371.camel@localhost> Just to clarify things for all Cabal hackers with commit access to darcs.haskell.org: We have a number of Cabal branches: (using darcs ssh push style urls) Cabal HEAD: darcs.haskell.org:/srv/darcs/cabal Cabal 1.2 branch: darcs.haskell.org:/srv/darcs/cabal-branches/cabal-1.2 GHC HEAD's copy of Cabal: darcs.haskell.org:/srv/darcs/packages/Cabal The Cabal HEAD repo is where new patches should go. If you have access to darcs.haskell.org and you don't think your patch needs wider review then you can just push to this repo. The other two repos are used by versions of GHC and the GHC nightly builds. It's important not to break GHC builds so any patches pushed to these repos requires running the GHC validate test first. The Cabal 1.2 branch is uses by the GHC 6.8 branch and the other one is used by GHC HEAD. So of course you'd have to run the validate script for the appropriate GHC branch. The easiest thing to do is ignore the second two branches and just target Cabal HEAD and let other GHC and Cabal maintainers migrate patches from Cabal HEAD to the other repos as appropriate. Though if you think a patch should go to the Cabal-1.2 branch you should probably say so. Clear as mud? Duncan From duncan.coutts at worc.ox.ac.uk Thu Sep 6 11:24:19 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 11:14:41 2007 Subject: patch applied (cabal-branches/cabal-1.2): spell nhc98-options correctly Message-ID: <20070906152419.GA31093@cvs.haskell.org> Thu Sep 6 08:04:11 PDT 2007 Malcolm.Wallace@cs.york.ac.uk * spell nhc98-options correctly M ./Cabal.cabal -1 +1 From Malcolm.Wallace at cs.york.ac.uk Thu Sep 6 12:22:02 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Sep 6 12:12:26 2007 Subject: patch applied (cabal): fix broken #ifdefs for nhc98 Message-ID: <20070906162202.GA972@cvs.haskell.org> Thu Sep 6 09:15:53 PDT 2007 Malcolm.Wallace@cs.york.ac.uk * fix broken #ifdefs for nhc98 M ./Distribution/Compat/Directory.hs -2 +2 M ./Distribution/Configuration.hs -1 +1 From Malcolm.Wallace at cs.york.ac.uk Thu Sep 6 12:32:09 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Sep 6 12:22:31 2007 Subject: patch applied (cabal): fix type clash: Data.Version -> Distribution.Version Message-ID: <20070906163209.GA1684@cvs.haskell.org> Thu Sep 6 09:30:51 PDT 2007 Malcolm.Wallace@cs.york.ac.uk * fix type clash: Data.Version -> Distribution.Version M ./Distribution/Simple/InstallDirs.hs -1 +1 From nominolo at googlemail.com Thu Sep 6 12:35:19 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Sep 6 12:25:48 2007 Subject: ANNOUNCE: Cabal 1.2.0 released Message-ID: <1189096519.18535.2.camel@intothevoid> The Haskell Cabal The Common Architecture for Building Applications and Libraries. We are pleased to announce that Cabal version 1.2.0 is now available. Changes: The major new feature in this release is support for Cabal configurations. This allows package authors to more easily adopt their package descriptions to different system parameters such as operating system, architecture, or compiler. In addition, some optional features may be enabled or disabled explicitly by the package user. Many other new features and tool support has been added, among others: - Support for hscolour (haddock links to coloured source code). - Support for pkg-config (allows specifying dependencies on many C libraries). - Specification of build-tool dependencies. - Better default installation paths on Windows. - Seperate "includes" and "install-includes" fields - Install paths can be specified relative to each other. - Many more new small features, command line flags and bugfixes. For a more exhaustive list, see http://www.haskell.org/cabal/release/rc/changelog Please note that this is a .0 release, so we would appreciate any feedback or bug reports. Note also, that the hooks API changed, so it's quite likely that many non-trivial Setup.[l]hs files will break. We hope, however, that much of those files' functionality can now be expressed using configurations. This version (or a bug fix update) will be included in GHC version 6.8.1. For other Haskell implementations or older versions of GHC you can install it separately: Download: http://www.haskell.org/cabal/download.html http://haskell.org/cabal/release/rc/cabal-1.2.0.tar.gz Documentation: http://www.haskell.org/cabal/release/rc/doc/users-guide/ http://www.haskell.org/cabal/release/rc/doc/API/Cabal See both the README file and the changelog for interface changes: http://www.haskell.org/cabal/release/rc/changelog Bugs: Report bugs using our bug tracker: http://hackage.haskell.org/trac/hackage/newticket or at the libraries@haskell.org (please CC to cabal-devel@haskell.org) mailing list (note that this is subscriber only). From nominolo at googlemail.com Thu Sep 6 14:32:28 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Sep 6 14:22:57 2007 Subject: ANNOUNCE: Cabal 1.2.0 released In-Reply-To: <35649258.20070906210033@gmail.com> References: <1189096519.18535.2.camel@intothevoid> <35649258.20070906210033@gmail.com> Message-ID: <1189103548.18535.9.camel@intothevoid> On Thu, 2007-09-06 at 21:00 +0400, Bulat Ziganshin wrote: > Hello Thomas, > > Thursday, September 6, 2007, 8:35:19 PM, you wrote: > > We are pleased to announce that Cabal version 1.2.0 is now available. > > i suggest you to forward announce into main haskell maillist too > > major release of such important library is definitely news interesting > for many haskellers Well, I think I should have been a little clearer about the status of this release. Let me clarify. Earlier releases were preceded by release candidates before the .0 release. However, we changed it this time so that .0 basically is the release candidate and .1 will then be the first stable release. Therefore, we decided to post only to the developer mailing lists, so that the first release to the wider public (1.2.1) will, hopefully, have most issues resolved. / Thomas From duncan.coutts at worc.ox.ac.uk Thu Sep 6 14:52:47 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 14:41:08 2007 Subject: ANNOUNCE: Cabal 1.2.0 released In-Reply-To: <1189103548.18535.9.camel@intothevoid> References: <1189096519.18535.2.camel@intothevoid> <35649258.20070906210033@gmail.com> <1189103548.18535.9.camel@intothevoid> Message-ID: <1189104767.10322.388.camel@localhost> On Thu, 2007-09-06 at 20:32 +0200, Thomas Schilling wrote: > On Thu, 2007-09-06 at 21:00 +0400, Bulat Ziganshin wrote: > > i suggest you to forward announce into main haskell maillist too > > > > major release of such important library is definitely news interesting > > for many haskellers > Well, I think I should have been a little clearer about the status of > this release. Let me clarify. > > Earlier releases were preceded by release candidates before the .0 > release. However, we changed it this time so that .0 basically is the > release candidate and .1 will then be the first stable release. > Therefore, we decided to post only to the developer mailing lists, so > that the first release to the wider public (1.2.1) will, hopefully, have > most issues resolved. The corollary to that of course is a request to everyone to please test the new release and see if your most important pet Cabal bugs have been fixed or if there are any regressions. You can get a reasonably accurate view of what bugs we know about from our bug tracker: http://hackage.haskell.org/trac/hackage/ So if it's not listed there, assume we do not know about it and please report it. We can't promise to fix everything but we can at least not forget stuff and try and prioritise things for future point releases. This is also the opportunity for package developers to try out the new configurations feature before ghc-6.8 comes out and fix to up any Setup.lhs scripts (or get rid of them if possible). Note that, at the moment hackage probably will not accept packages using configurations since it will not be able to parse them. We'll need to update the cabal lib on hackage. There's also an interesting problem for hackage clients like cabal-install since they will not be able to parse .cabal files that use configurations until they are updated. One solution is for hackage to bump the index format, to 01-index.tar.gz. So the 00-index.tar.gz would continue to have packages that do not use configurations and the 01-index.tar.gz would have all packages including newer ones using configurations syntax. So older clients would be blissfully unaware and new clients could look for the new index file. Duncan From pgavin at gmail.com Thu Sep 6 17:03:13 2007 From: pgavin at gmail.com (Peter Gavin) Date: Thu Sep 6 16:53:34 2007 Subject: patch applied (cabal-branches/cabal-1.2): spell nhc98-options correctly In-Reply-To: <20070906152419.GA31093@cvs.haskell.org> References: <20070906152419.GA31093@cvs.haskell.org> Message-ID: <37df87420709061403t4a21eff6ga69860a162f07e10@mail.gmail.com> I'd assume these patches get applied in batches (e.g., many in a single command). Is there any way these emails can reduced to one per batch, instead of one per patch? Pete On 9/6/07, Duncan Coutts wrote: > Thu Sep 6 08:04:11 PDT 2007 Malcolm.Wallace@cs.york.ac.uk > * spell nhc98-options correctly > > M ./Cabal.cabal -1 +1 > _______________________________________________ > cabal-devel mailing list > cabal-devel@haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > From clemens at endorphin.org Thu Sep 6 17:33:33 2007 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Thu Sep 6 17:23:56 2007 Subject: patch applied (cabal): Add shared library building to GHC module (also via Makefile) Message-ID: <20070906213333.GA8609@cvs.haskell.org> Thu Sep 6 14:31:32 PDT 2007 Clemens Fruhwirth * Add shared library building to GHC module (also via Makefile) M ./Distribution/Simple/GHC.hs -25 +67 M ./Distribution/Simple/GHC/Makefile.in -3 +16 M ./Distribution/Simple/Install.hs -3 +1 From clemens at endorphin.org Thu Sep 6 17:36:39 2007 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Thu Sep 6 17:27:02 2007 Subject: patch applied (cabal): Update D.S.GHC/Makefile.hs Message-ID: <20070906213639.GA8769@cvs.haskell.org> Thu Sep 6 14:35:07 PDT 2007 Clemens Fruhwirth * Update D.S.GHC/Makefile.hs M ./Distribution/Simple/GHC/Makefile.hs -1 +1 From duncan.coutts at worc.ox.ac.uk Thu Sep 6 18:00:49 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 6 17:49:09 2007 Subject: patch applied (cabal-branches/cabal-1.2): spell nhc98-options correctly In-Reply-To: <37df87420709061403t4a21eff6ga69860a162f07e10@mail.gmail.com> References: <20070906152419.GA31093@cvs.haskell.org> <37df87420709061403t4a21eff6ga69860a162f07e10@mail.gmail.com> Message-ID: <1189116049.10322.392.camel@localhost> On Thu, 2007-09-06 at 17:03 -0400, Peter Gavin wrote: > I'd assume these patches get applied in batches (e.g., many in a > single command). Is there any way these emails can reduced to one per > batch, instead of one per patch? It was done this way deliberately at the time that patches were going to the libraries commit mailing list. It does make somewhat less sense now that the emails are going to cabal-devel. What do other people think? Duncan From igloo at earth.li Thu Sep 6 18:04:55 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 6 17:55:17 2007 Subject: patch applied (cabal-branches/cabal-1.2): spell nhc98-options correctly In-Reply-To: <1189116049.10322.392.camel@localhost> References: <20070906152419.GA31093@cvs.haskell.org> <37df87420709061403t4a21eff6ga69860a162f07e10@mail.gmail.com> <1189116049.10322.392.camel@localhost> Message-ID: <20070906220454.GA30086@matrix.chaos.earth.li> On Thu, Sep 06, 2007 at 10:00:49PM +0000, Duncan Coutts wrote: > On Thu, 2007-09-06 at 17:03 -0400, Peter Gavin wrote: > > I'd assume these patches get applied in batches (e.g., many in a > > single command). Is there any way these emails can reduced to one per > > batch, instead of one per patch? > > It was done this way deliberately at the time that patches were going to > the libraries commit mailing list. It does make somewhat less sense now > that the emails are going to cabal-devel. > > What do other people think? I prefer a separate mail per patch. I don't mind which list it goes to, as long as it is only 1 list. Thanks Ian From trac at galois.com Thu Sep 6 20:46:47 2007 From: trac at galois.com (Hackage) Date: Thu Sep 6 20:37:09 2007 Subject: [Hackage] #141: Cabal throws an ugly "irrefutable pattern match failed" error when confronted to an empty .cabal descriptor In-Reply-To: <054.4823ca01d93633b5c26b4f48db3917d3@localhost> References: <054.4823ca01d93633b5c26b4f48db3917d3@localhost> Message-ID: <063.bf33782f7c81c3891dc5d2a2c19804f6@localhost> #141: Cabal throws an ugly "irrefutable pattern match failed" error when confronted to an empty .cabal descriptor ----------------------------------+----------------------------------------- Reporter: mnislaih | Owner: mnislaih Type: defect | Status: closed Priority: low | Milestone: Component: Cabal | Version: HEAD Severity: minor | Resolution: fixed Keywords: | Ghcversion: 6.6 Difficulty: very easy (<1 hour) | Platform: Mac OS ----------------------------------+----------------------------------------- Changes (by duncan): * resolution: => fixed * status: new => closed Comment: We now get {{{ setup: Warning: No library or executable specified Configuring ... setup: Warning: No executables and no library found. Nothing to do. setup: Warning: No exposed modules or executables in this package. setup: Warning: No license-file field. setup: Error: Missing field: name setup: Error: Missing field: version }}} I suppose it could be better yet. -- Ticket URL: Hackage My example project From trac at galois.com Thu Sep 6 20:49:19 2007 From: trac at galois.com (Hackage) Date: Thu Sep 6 20:39:40 2007 Subject: [Hackage] #27: Document configurations syntax In-Reply-To: <054.e08634b3554390389fe2e0911213bf6f@localhost> References: <054.e08634b3554390389fe2e0911213bf6f@localhost> Message-ID: <063.a1ed177efc46b4452e330b567f17d559@localhost> #27: Document configurations syntax ----------------------------------------------------+----------------------- Reporter: Simon Marlow | Owner: nominolo Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.2 Component: Cabal | Version: Severity: normal | Resolution: Keywords: | Difficulty: very easy (<1 hour) Ghcversion: 6.2.1 | Platform: Linux ----------------------------------------------------+----------------------- Changes (by duncan): * difficulty: very hard => very easy (<1 hour) * milestone: Cabal-1.4 => Cabal-1.2 * summary: Configurations => Document configurations syntax Comment: Configurations are now implemented, the latest syntax needs to be documented in the user guide. -- Ticket URL: Hackage My example project From trac at galois.com Thu Sep 6 20:50:32 2007 From: trac at galois.com (Hackage) Date: Thu Sep 6 20:40:53 2007 Subject: [Hackage] #132: Add "tools" field (like "extensions") In-Reply-To: <054.1fe9a6c1688a5f1f552ac6596788f2a4@localhost> References: <054.1fe9a6c1688a5f1f552ac6596788f2a4@localhost> Message-ID: <063.9157970c701e28324a807e6317acd7b4@localhost> #132: Add "tools" field (like "extensions") --------------------------+------------------------------------------------- Reporter: guest | Owner: ijones Type: enhancement | Status: closed Priority: high | Milestone: Cabal-1.2 Component: Cabal | Version: HEAD Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.4.2 | Platform: Linux --------------------------+------------------------------------------------- Changes (by duncan): * resolution: => fixed * status: new => closed -- Ticket URL: Hackage My example project From ross at soi.city.ac.uk Sat Sep 8 09:48:30 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Sep 8 09:39:25 2007 Subject: ANNOUNCE: Cabal 1.2.0 released In-Reply-To: <1189104767.10322.388.camel@localhost> References: <1189096519.18535.2.camel@intothevoid> <35649258.20070906210033@gmail.com> <1189103548.18535.9.camel@intothevoid> <1189104767.10322.388.camel@localhost> Message-ID: <20070908134830.GA3116@soi.city.ac.uk> On Thu, Sep 06, 2007 at 06:52:47PM +0000, Duncan Coutts wrote: > Note that, at the moment hackage probably will not accept packages using > configurations since it will not be able to parse them. It should accept them now. But people adding new packages should specify their dependencies properly. There are already a few in there that need the unreleased base-2.1 but don't say so. > There's also an interesting problem for > hackage clients like cabal-install since they will not be able to > parse .cabal files that use configurations until they are updated. One > solution is for hackage to bump the index format, to 01-index.tar.gz. So > the 00-index.tar.gz would continue to have packages that do not use > configurations and the 01-index.tar.gz would have all packages including > newer ones using configurations syntax. So older clients would be > blissfully unaware and new clients could look for the new index file. The clients are just cabal-install and autodoc, as far as I know. We should probably just update them. From ross at soi.city.ac.uk Sun Sep 9 05:21:20 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Sep 9 05:17:24 2007 Subject: build-depends in old-style package descriptions Message-ID: <20070909092120.GA2652@soi.city.ac.uk> The build-depends field has been moved from the package level to the individual library and executable components. (And the new build-tools and pkgconfig-depends fields are similarly attached to components.) I'm not sure whether this is a good idea, but more specifically I came across this in the parser for old-style package descriptions in Distribution.PackageDescription: -- The 'build-depends' field was global so far. Now it's -- supported in each section. -- XXX: we actially have two options here -- (1) put all dependencies into the library section, if the -- library section would be empty, mark it as not buildable -- (2) duplicate all dependencies in each section, libraries -- and executables -- Right now we go with (1) Surely (1) is just wrong. Is there any reason not to do (2)? From duncan.coutts at worc.ox.ac.uk Sun Sep 9 06:27:13 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Sep 9 06:15:24 2007 Subject: ANNOUNCE: Cabal 1.2.0 released In-Reply-To: <20070908134830.GA3116@soi.city.ac.uk> References: <1189096519.18535.2.camel@intothevoid> <35649258.20070906210033@gmail.com> <1189103548.18535.9.camel@intothevoid> <1189104767.10322.388.camel@localhost> <20070908134830.GA3116@soi.city.ac.uk> Message-ID: <1189333633.10322.424.camel@localhost> On Sat, 2007-09-08 at 14:48 +0100, Ross Paterson wrote: > On Thu, Sep 06, 2007 at 06:52:47PM +0000, Duncan Coutts wrote: > > Note that, at the moment hackage probably will not accept packages using > > configurations since it will not be able to parse them. > > It should accept them now. But people adding new packages should specify > their dependencies properly. There are already a few in there that need > the unreleased base-2.1 but don't say so. That really really needs a version bump, ghc-6.6.1 cam with base-2.1.1 > > There's also an interesting problem for > > hackage clients like cabal-install since they will not be able to > > parse .cabal files that use configurations until they are updated. One > > solution is for hackage to bump the index format, to 01-index.tar.gz. So > > the 00-index.tar.gz would continue to have packages that do not use > > configurations and the 01-index.tar.gz would have all packages including > > newer ones using configurations syntax. So older clients would be > > blissfully unaware and new clients could look for the new index file. > > The clients are just cabal-install and autodoc, as far as I know. > We should probably just update them. Yeah, I guess so. There's also HackPort, but we can also easily update that and it's not in wide use yet. Duncan From nominolo at googlemail.com Sun Sep 9 09:18:43 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Sep 9 09:09:01 2007 Subject: build-depends in old-style package descriptions In-Reply-To: <20070909092120.GA2652@soi.city.ac.uk> References: <20070909092120.GA2652@soi.city.ac.uk> Message-ID: <1189343923.23801.6.camel@intothevoid> On Sun, 2007-09-09 at 10:21 +0100, Ross Paterson wrote: > The build-depends field has been moved from the package level to the > individual library and executable components. (And the new build-tools > and pkgconfig-depends fields are similarly attached to components.) > I'm not sure whether this is a good idea, but more specifically I > came across this in the parser for old-style package descriptions in > Distribution.PackageDescription: > > -- The 'build-depends' field was global so far. Now it's > -- supported in each section. > -- XXX: we actially have two options here > -- (1) put all dependencies into the library section, if the > -- library section would be empty, mark it as not buildable > -- (2) duplicate all dependencies in each section, libraries > -- and executables > -- Right now we go with (1) > > Surely (1) is just wrong. Is there any reason not to do (2)? (1) was easier at the time. (2) should be relatively easy to implement now, but since the current implementation works, I didn't bother so far. I know that (1) is a rather hackish solution, but why is it "just wrong"? (After all, it works.) From ross at soi.city.ac.uk Sun Sep 9 09:42:34 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Sep 9 09:32:59 2007 Subject: build-depends in old-style package descriptions In-Reply-To: <1189343923.23801.6.camel@intothevoid> References: <20070909092120.GA2652@soi.city.ac.uk> <1189343923.23801.6.camel@intothevoid> Message-ID: <20070909134234.GA2611@soi.city.ac.uk> On Sun, Sep 09, 2007 at 03:18:43PM +0200, Thomas Schilling wrote: > (1) was easier at the time. (2) should be relatively easy to implement > now, but since the current implementation works, I didn't bother so far. > I know that (1) is a rather hackish solution, but why is it "just > wrong"? (After all, it works.) It makes a package that doesn't contain a library look like it does have one (though unbuildable). I think there's an important difference between the two cases; it certainly matters to clients. From nominolo at googlemail.com Sun Sep 9 11:37:32 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Sep 9 11:27:53 2007 Subject: build-depends in old-style package descriptions In-Reply-To: <20070909134234.GA2611@soi.city.ac.uk> References: <20070909092120.GA2652@soi.city.ac.uk> <1189343923.23801.6.camel@intothevoid> <20070909134234.GA2611@soi.city.ac.uk> Message-ID: <1189352252.23801.12.camel@intothevoid> On Sun, 2007-09-09 at 14:42 +0100, Ross Paterson wrote: > On Sun, Sep 09, 2007 at 03:18:43PM +0200, Thomas Schilling wrote: > > (1) was easier at the time. (2) should be relatively easy to implement > > now, but since the current implementation works, I didn't bother so far. > > I know that (1) is a rather hackish solution, but why is it "just > > wrong"? (After all, it works.) > > It makes a package that doesn't contain a library look like it does > have one (though unbuildable). I think there's an important difference > between the two cases; it certainly matters to clients. Note that it does not rewrite the _external_ package description. Cabal now internally uses the section-based syntax, so we have to rewrite old flat package descriptions to the section-based format _internally_. I.e., the actual text-file is never overridden, so no end-user will ever see this. From ross at soi.city.ac.uk Sun Sep 9 12:22:51 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Sep 9 12:13:09 2007 Subject: build-depends in old-style package descriptions In-Reply-To: <1189352252.23801.12.camel@intothevoid> References: <20070909092120.GA2652@soi.city.ac.uk> <1189343923.23801.6.camel@intothevoid> <20070909134234.GA2611@soi.city.ac.uk> <1189352252.23801.12.camel@intothevoid> Message-ID: <20070909162251.GA5015@soi.city.ac.uk> On Sun, Sep 09, 2007 at 05:37:32PM +0200, Thomas Schilling wrote: > Note that it does not rewrite the _external_ package description. Cabal > now internally uses the section-based syntax, so we have to rewrite old > flat package descriptions to the section-based format _internally_. > I.e., the actual text-file is never overridden, so no end-user will ever > see this. I realize that -- I'm concerned about clients of the Cabal library (e.g. the HackageDB scripts), whose view of the package description goes through this function. From trac at galois.com Mon Sep 10 12:26:02 2007 From: trac at galois.com (Hackage) Date: Mon Sep 10 12:16:11 2007 Subject: [Hackage] #153: Cabal makes empty data directories Message-ID: <054.01a90556d65485abd21872ebbbd6886c@localhost> #153: Cabal makes empty data directories ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | ---------------------+------------------------------------------------------ In http://www.haskell.org/pipermail/cvs-ghc/2007-September/038121.html Sven writes: {{{ The current Cabal used for building GHC has a small bug, it *always* creates the data directory, even if there are no data files in the package. Simple fix: *** /tmp/Install.hs 2007-09-09 14:56:50.000000000 +0200 --- Distribution/Simple/Install.hs 2007-09-09 12:57:21.000000000 +0200 *************** *** 115,121 **** (putStrLn ("directory " ++ haddockPref pkg_descr ++ " does exist: " ++ show docExists)) when (dataFilesExist || docExists) $ do - createDirectoryIfMissingVerbose verbosity True dataPref flip mapM_ (dataFiles pkg_descr) $ \ file -> do let dir = takeDirectory file createDirectoryIfMissingVerbose verbosity True (dataPref dir) --- 115,120 ---- Nothing substantial, but this leads to lots of useless empty directories when GHC is installed. Feel free to apply this fix in the right repository... (No idea which) }}} -- Ticket URL: Hackage My example project From duncan.coutts at worc.ox.ac.uk Wed Sep 12 07:31:43 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Sep 12 07:21:50 2007 Subject: patch applied (cabal): Use confgurations to help build Cabal for ghc-6.2.x Message-ID: <20070912113143.GA16212@cvs.haskell.org> Wed Sep 12 04:29:34 PDT 2007 Duncan Coutts * Use confgurations to help build Cabal for ghc-6.2.x Replacing a long-standing comment telling people how to do it manually. M ./Cabal.cabal -1 +3 From trac at galois.com Wed Sep 12 07:40:54 2007 From: trac at galois.com (Hackage) Date: Wed Sep 12 07:30:58 2007 Subject: [Hackage] #153: Cabal makes empty data directories In-Reply-To: <054.01a90556d65485abd21872ebbbd6886c@localhost> References: <054.01a90556d65485abd21872ebbbd6886c@localhost> Message-ID: <063.35d229e939a9735bc88ad15cfd04d83a@localhost> #153: Cabal makes empty data directories ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------+------------------------------------------------------ Changes (by duncan): * resolution: => fixed * status: new => closed Comment: Applied, thanks. -- Ticket URL: Hackage My example project From duncan.coutts at worc.ox.ac.uk Wed Sep 12 07:40:54 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Sep 12 07:30:58 2007 Subject: patch applied (cabal): Don't create empty data dirs. Fixes bug #153. Message-ID: <20070912114054.GA16497@cvs.haskell.org> Wed Sep 12 04:38:03 PDT 2007 Duncan Coutts * Don't create empty data dirs. Fixes bug #153. Patch contributed by Sven Panne. M ./Distribution/Simple/Install.hs -5 +2 From trac at galois.com Wed Sep 12 11:09:37 2007 From: trac at galois.com (Hackage) Date: Wed Sep 12 10:59:41 2007 Subject: [Hackage] #104: "setup install" should configure and build if necessary In-Reply-To: <054.2d85156134065e8549dcec5f7f46139b@localhost> References: <054.2d85156134065e8549dcec5f7f46139b@localhost> Message-ID: <063.fec759216c84836880a9dd8a5f8bb29f@localhost> #104: "setup install" should configure and build if necessary ---------------------+------------------------------------------------------ Reporter: guest | Owner: ijones Type: task | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.4.2 | Platform: Linux ---------------------+------------------------------------------------------ Changes (by duncan): * milestone: Cabal-1.2 => Comment: I'm not sure if cabal-install reduces the desire for this feature. -- Ticket URL: Hackage My example project From trac at galois.com Wed Sep 12 11:12:33 2007 From: trac at galois.com (Hackage) Date: Wed Sep 12 11:02:37 2007 Subject: [Hackage] #110: cabal should detect when a new version of a library is installed In-Reply-To: <054.6e1e30e736b19d964843475e26f833c6@localhost> References: <054.6e1e30e736b19d964843475e26f833c6@localhost> Message-ID: <063.29fa47ecddd8110d0340c462d14e7e59@localhost> #110: cabal should detect when a new version of a library is installed --------------------------------+------------------------------------------- Reporter: guest | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: rebuild timestamp | Difficulty: normal Ghcversion: 6.6 | Platform: Linux --------------------------------+------------------------------------------- Changes (by duncan): * milestone: Cabal-1.2 => Comment: Currently recompilation checking is deferred to ghc and it does not check packages at the moment. See http://hackage.haskell.org/trac/ghc/ticket/1372 -- Ticket URL: Hackage My example project From trac at galois.com Wed Sep 12 11:38:34 2007 From: trac at galois.com (Hackage) Date: Wed Sep 12 11:28:37 2007 Subject: [Hackage] #65: reorganize layered tool system (cabal-get, cabal-install, cabal-setup, etc) In-Reply-To: <054.27bb3d43a0469bb39a648b79cc0845ac@localhost> References: <054.27bb3d43a0469bb39a648b79cc0845ac@localhost> Message-ID: <063.f6c86ee3a4b40b0d9658119e1a0a7de6@localhost> #65: reorganize layered tool system (cabal-get, cabal-install, cabal-setup, etc) --------------------------+------------------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: Severity: major | Resolution: Keywords: | Difficulty: very hard Ghcversion: 6.2.1 | Platform: Linux --------------------------+------------------------------------------------- Changes (by duncan): * ghcversion: => 6.2.1 * milestone: Cabal-1.2 => * platform: => Linux Comment: As of cabal-1.2 we have a separate cabal-setup that's just a command line wrapper over Setup.(l)hs files and a cabal-install program that downloads and installs packages and deps from hackage. -- Ticket URL: Hackage My example project From trac at galois.com Wed Sep 12 11:43:35 2007 From: trac at galois.com (Hackage) Date: Wed Sep 12 11:33:38 2007 Subject: [Hackage] #24: Cabal shouldn't try to build GHCI libs on platforms without GHCI In-Reply-To: <054.a7b8ee364d385939a025c46480f410ef@localhost> References: <054.a7b8ee364d385939a025c46480f410ef@localhost> Message-ID: <063.11acf948b895f5ef2d48b96d080d21b3@localhost> #24: Cabal shouldn't try to build GHCI libs on platforms without GHCI ------------------------------------+--------------------------------------- Reporter: jgoerzen@complete.org | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal | Version: Severity: normal | Resolution: Keywords: | Difficulty: hard Ghcversion: 6.2.1 | Platform: Linux ------------------------------------+--------------------------------------- Changes (by duncan): * ghcversion: => 6.2.1 * milestone: Cabal-1.2 => Cabal-1.4 * platform: => Linux Comment: ghc-6.8 has a flag that tells us various features about the ghc installation. I think that the ghci support is one of these things. So we could support this feature in ghc-6.8 and later. If we do this, should we drop the existing --disable-library-for-ghci flag? We could keep it if we tried the {{{ghc -e "return ()"}}} suggestion. -- Ticket URL: Hackage My example project From igloo at earth.li Wed Sep 12 12:01:24 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 12 11:51:31 2007 Subject: patch applied (cabal-branches/cabal-1.2): TAG 2007-09-06 Message-ID: <20070912160124.GA24494@cvs.haskell.org> Thu Sep 6 14:21:50 PDT 2007 Ian Lynagh tagged 2007-09-06 From igloo at earth.li Wed Sep 12 12:01:26 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 12 11:51:32 2007 Subject: patch applied (cabal-branches/cabal-1.2): Don't forcibly append "pkgName (package pkg_descr)" to htmldir Message-ID: <20070912160126.GA24508@cvs.haskell.org> Tue Sep 11 12:28:14 PDT 2007 Ian Lynagh * Don't forcibly append "pkgName (package pkg_descr)" to htmldir M ./Distribution/Simple/Install.hs -4 +3 From igloo at earth.li Wed Sep 12 12:01:27 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 12 11:51:32 2007 Subject: patch applied (cabal-branches/cabal-1.2): Add a --htmldir flag Message-ID: <20070912160127.GA24522@cvs.haskell.org> Wed Sep 12 05:21:45 PDT 2007 Ian Lynagh * Add a --htmldir flag M ./Distribution/Simple/Configure.hs -2 +2 M ./Distribution/Simple/Setup.hs -1 +8 M ./doc/Cabal.xml +28 From igloo at earth.li Wed Sep 12 12:01:29 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 12 11:51:35 2007 Subject: patch applied (cabal-branches/cabal-1.2): Add htmlDirTemplate to inplaceDirs Message-ID: <20070912160129.GA24536@cvs.haskell.org> Wed Sep 12 05:57:49 PDT 2007 Ian Lynagh * Add htmlDirTemplate to inplaceDirs M ./Distribution/Simple/Register.hs -1 +2 From igloo at earth.li Wed Sep 12 12:01:30 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 12 11:51:36 2007 Subject: patch applied (cabal-branches/cabal-1.2): Fix haddockDir Message-ID: <20070912160130.GA24551@cvs.haskell.org> Wed Sep 12 06:30:51 PDT 2007 Ian Lynagh * Fix haddockDir M ./Distribution/Simple/InstallDirs.hs -1 +1 M ./Distribution/Simple/Register.hs -1 +1 From igloo at earth.li Wed Sep 12 12:05:02 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 12 11:55:05 2007 Subject: patch applied (cabal): TAG 2007-09-06 Message-ID: <20070912160502.GA24874@cvs.haskell.org> Thu Sep 6 14:21:50 PDT 2007 Ian Lynagh tagged 2007-09-06 From igloo at earth.li Wed Sep 12 12:05:04 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 12 11:55:07 2007 Subject: patch applied (cabal): Don't forcibly append "pkgName (package pkg_descr)" to htmldir Message-ID: <20070912160504.GA24888@cvs.haskell.org> Tue Sep 11 12:28:14 PDT 2007 Ian Lynagh * Don't forcibly append "pkgName (package pkg_descr)" to htmldir M ./Distribution/Simple/Install.hs -4 +3 From igloo at earth.li Wed Sep 12 12:05:05 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 12 11:55:12 2007 Subject: patch applied (cabal): Add a --htmldir flag Message-ID: <20070912160505.GA24904@cvs.haskell.org> Wed Sep 12 05:21:45 PDT 2007 Ian Lynagh * Add a --htmldir flag M ./Distribution/Simple/Configure.hs -2 +2 M ./Distribution/Simple/Setup.hs -1 +8 M ./doc/Cabal.xml +28 From igloo at earth.li Wed Sep 12 12:05:07 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 12 11:55:13 2007 Subject: patch applied (cabal): Add htmlDirTemplate to inplaceDirs Message-ID: <20070912160507.GA24918@cvs.haskell.org> Wed Sep 12 05:57:49 PDT 2007 Ian Lynagh * Add htmlDirTemplate to inplaceDirs M ./Distribution/Simple/Register.hs -1 +2 From igloo at earth.li Wed Sep 12 12:05:08 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Sep 12 11:55:13 2007 Subject: patch applied (cabal): Fix haddockDir Message-ID: <20070912160508.GA24933@cvs.haskell.org> Wed Sep 12 06:30:51 PDT 2007 Ian Lynagh * Fix haddockDir M ./Distribution/Simple/InstallDirs.hs -1 +1 M ./Distribution/Simple/Register.hs -1 +1 From judah.jacobson at gmail.com Thu Sep 13 17:38:47 2007 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Thu Sep 13 17:38:45 2007 Subject: Problem configuring c2hs with Cabal-1.2 Message-ID: <6d74b0d20709131438q18ff557ex1b61e42e8ed5dec5@mail.gmail.com> I just downloaded c2hs (HEAD version) and tried to run "runhaskell Setup.hs configure" using the ghc 6.8 release candidate (i.e., Cabal 1.2), and got the following error: > Configuring c2hs-0.15.0... > Setup.hs: Error: Non-empty library, but empty exposed modules list. Cabal may not build this library correctly The .cabal file is parseable by ghc-6.6.1 (with Cabal 1.1.6.2). It's unclear to me whether this counts as a c2hs bug or a Cabal bug (maybe the above message should only be a warning?), so I'm cc'ing both lists. Also note that regardless, c2hs will need to be updated to work with base-2.0; when I tried ghc-6.8 with Cabal-1.1.6, I got the following error: > base/state/CIO.hs:71:7: > Could not find module `System.Cmd': > it is a member of package process-1.0, which is hidden Best, -Judah From nominolo at googlemail.com Thu Sep 13 18:38:55 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Sep 13 18:39:02 2007 Subject: Problem configuring c2hs with Cabal-1.2 In-Reply-To: <6d74b0d20709131438q18ff557ex1b61e42e8ed5dec5@mail.gmail.com> References: <6d74b0d20709131438q18ff557ex1b61e42e8ed5dec5@mail.gmail.com> Message-ID: <1189723135.26060.11.camel@intothevoid> On Thu, 2007-09-13 at 14:38 -0700, Judah Jacobson wrote: > I just downloaded c2hs (HEAD version) and tried to run "runhaskell > Setup.hs configure" using the ghc 6.8 release candidate (i.e., Cabal > 1.2), and got the following error: > > > Configuring c2hs-0.15.0... > > Setup.hs: Error: Non-empty library, but empty exposed modules list. Cabal may not build this library correctly > > The .cabal file is parseable by ghc-6.6.1 (with Cabal 1.1.6.2). It's > unclear to me whether this counts as a c2hs bug or a Cabal bug (maybe > the above message should only be a warning?), so I'm cc'ing both > lists. > > Also note that regardless, c2hs will need to be updated to work with > base-2.0; when I tried ghc-6.8 with Cabal-1.1.6, I got the following > error: > > > base/state/CIO.hs:71:7: > > Could not find module `System.Cmd': > > it is a member of package process-1.0, which is hidden Thanks for the report. The quick fix is to comment out the build-tools field. The other solution would be to use the sectionized format and move the build-tools and build-depends fields into the executable section, i.e., Executable c2hs Build-Depends: base, filepath Build-Tools: happy, alex -- ... The problem with this is, that this will require Cabal-1.2 and will not be backwards compatible to old versions of Cabal(!). (If you use an old Cabal on that same file you should actually get a warning about an unknown field during configure.) The error when using Cabal < 1.2, however, is most likely not related to Cabal, but to the base split-up, i.e., c2hs probably has to depend on 'process' if 'base >= 2.0'. Of course, the current dying of Cabal is not acceptable, I'm working on a patch. Thanks, / Thomas From igloo at earth.li Fri Sep 14 12:26:23 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Sep 14 12:26:18 2007 Subject: patch applied (cabal-branches/cabal-1.2): Add a boring file Message-ID: <20070914162623.GA7643@cvs.haskell.org> Thu Sep 13 13:35:50 PDT 2007 Ian Lynagh * Add a boring file A ./.darcs-boring From ross at soi.city.ac.uk Fri Sep 14 13:12:44 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Sep 14 13:12:54 2007 Subject: cpphs and C++-style comments In-Reply-To: <20070914163905.5b336ab7.Malcolm.Wallace@cs.york.ac.uk> References: <20070913123152.GA4408@soi.city.ac.uk> <20070913123614.GA24002@matrix.chaos.earth.li> <20070913141318.3172fde8.Malcolm.Wallace@cs.york.ac.uk> <20070914091318.GA3043@soi.city.ac.uk> <20070914163905.5b336ab7.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20070914171244.GA11741@soi.city.ac.uk> On Fri, Sep 14, 2007 at 04:39:05PM +0100, Malcolm Wallace wrote: > > > Would you like to have separate option flags in cpphs for stripping > > > the different kinds of C comment? e.g. --strip and --stripAnsi? > > > > Separate options would resuscitate the Hugs build, so yes please. > > How about --strip-traditional or --strip-c89? > > OK, done. The new option is --strip-c89. Thanks. Now we have a conundrum: should Cabal 1.2 use the new option, and thus require the latest cpphs, or stick with the old option and be broken with the new cpphs? Cabal only invokes cpphs for non-GHC builds, so I'd say use it. From duncan.coutts at worc.ox.ac.uk Fri Sep 14 13:38:41 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Sep 14 13:38:35 2007 Subject: cpphs and C++-style comments In-Reply-To: <20070914171244.GA11741@soi.city.ac.uk> References: <20070913123152.GA4408@soi.city.ac.uk> <20070913123614.GA24002@matrix.chaos.earth.li> <20070913141318.3172fde8.Malcolm.Wallace@cs.york.ac.uk> <20070914091318.GA3043@soi.city.ac.uk> <20070914163905.5b336ab7.Malcolm.Wallace@cs.york.ac.uk> <20070914171244.GA11741@soi.city.ac.uk> Message-ID: <20070914173841.23E9094047@webmail220.herald.ox.ac.uk> In message <20070914171244.GA11741@soi.city.ac.uk> libraries@haskell.org, cabal-devel@haskell.org writes: > On Fri, Sep 14, 2007 at 04:39:05PM +0100, Malcolm Wallace wrote: > > > > Would you like to have separate option flags in cpphs for stripping > > > > the different kinds of C comment? e.g. --strip and --stripAnsi? > > > > > > Separate options would resuscitate the Hugs build, so yes please. > > > How about --strip-traditional or --strip-c89? > > > > OK, done. The new option is --strip-c89. > > Thanks. Now we have a conundrum: should Cabal 1.2 use the new option, > and thus require the latest cpphs, or stick with the old option and be > broken with the new cpphs? Cabal only invokes cpphs for non-GHC builds, > so I'd say use it. Cabal knows the version of cpphs so it can use the new flag or the old one depending on the version of cpphs being used. Duncan From ross at soi.city.ac.uk Fri Sep 14 13:50:36 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Sep 14 13:50:40 2007 Subject: cpphs and C++-style comments In-Reply-To: <20070914173841.23E9094047@webmail220.herald.ox.ac.uk> References: <20070913123152.GA4408@soi.city.ac.uk> <20070913123614.GA24002@matrix.chaos.earth.li> <20070913141318.3172fde8.Malcolm.Wallace@cs.york.ac.uk> <20070914091318.GA3043@soi.city.ac.uk> <20070914163905.5b336ab7.Malcolm.Wallace@cs.york.ac.uk> <20070914171244.GA11741@soi.city.ac.uk> <20070914173841.23E9094047@webmail220.herald.ox.ac.uk> Message-ID: <20070914175036.GB11741@soi.city.ac.uk> On Fri, Sep 14, 2007 at 06:38:41PM +0100, Duncan Coutts wrote: > In message <20070914171244.GA11741@soi.city.ac.uk> libraries@haskell.org, > cabal-devel@haskell.org writes: > > Thanks. Now we have a conundrum: should Cabal 1.2 use the new option, > > and thus require the latest cpphs, or stick with the old option and be > > broken with the new cpphs? Cabal only invokes cpphs for non-GHC builds, > > so I'd say use it. > > Cabal knows the version of cpphs so it can use the new flag or the old one > depending on the version of cpphs being used. OK, so time to bump the version number of cpphs, then? From Malcolm.Wallace at cs.york.ac.uk Fri Sep 14 16:06:33 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Sep 14 16:06:30 2007 Subject: cpphs and C++-style comments In-Reply-To: <20070914175036.GB11741@soi.city.ac.uk> References: <20070913123152.GA4408@soi.city.ac.uk> <20070913123614.GA24002@matrix.chaos.earth.li> <20070913141318.3172fde8.Malcolm.Wallace@cs.york.ac.uk> <20070914091318.GA3043@soi.city.ac.uk> <20070914163905.5b336ab7.Malcolm.Wallace@cs.york.ac.uk> <20070914171244.GA11741@soi.city.ac.uk> <20070914173841.23E9094047@webmail220.herald.ox.ac.uk> <20070914175036.GB11741@soi.city.ac.uk> Message-ID: <20070914210633.171c3b06.Malcolm.Wallace@cs.york.ac.uk> Ross Paterson writes: > > > Thanks. Now we have a conundrum: should Cabal 1.2 use the new option, > > > and thus require the latest cpphs, or stick with the old option and be > > > broken with the new cpphs? Hmm. There could be a better solution. Since no released version of cpphs has yet had the behaviour of stripping C eol // comments, (only the darcs version) there is still time to change the meaning of the flags. In particular, we could swap --strip back to mean what it used to mean (the current --strip-c89 behaviour), and find a new name for the eol-stripping flag. Thoughts? Regards, Malcolm From trac at galois.com Fri Sep 14 23:21:27 2007 From: trac at galois.com (Hackage) Date: Fri Sep 14 23:21:21 2007 Subject: [Hackage] #154: Cabal doesn't clean "_stub" files Message-ID: <054.422c9b3a9d4980d442ca8287152a85ea@localhost> #154: Cabal doesn't clean "_stub" files ---------------------+------------------------------------------------------ Reporter: judahj | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Mac OS | ---------------------+------------------------------------------------------ Running "runhaskell Setup.hs clean" doesn't clean _stub.{c,h} files in Cabal-1.2.0. It does in 1.1.6.2. The -stubdir flag might be useful here (introduced in ghc-6.6) for having them created in the dist/build directory. (In both 1.2.0 and 1.1.6.2, they're created next to the source .hs files.) Related: [542]. -- Ticket URL: Hackage My example project From trac at galois.com Sun Sep 16 14:27:40 2007 From: trac at galois.com (Hackage) Date: Sun Sep 16 14:27:28 2007 Subject: [Hackage] #155: show . readPackageDescription /= id Message-ID: <054.ce372c14aa81d72d11f6a6941f7d5b61@localhost> #155: show . readPackageDescription /= id ----------------------------------------+----------------------------------- Reporter: kolmodin@dtek.chalmers.se | Owner: nominolo Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Linux | ----------------------------------------+----------------------------------- Hi, if find the following a bit confusing: Read and then print a cabal file (old style without configurations is enough): {{{ pkg <- readPackageDescription normal "foo.cabal" -- :: IO GenericPackageDescription print pkg }}} That output is then not parsable by readPackageDescription, error: {{{ Test.hs: foo-copy.cabal26: Parse of field 'executable' failed: }}} It seems that the Show instance of GenericPackageDescription generates a string where the executables' entries cannot be parsed again. Cheers, Lennart K -- Ticket URL: Hackage My example project From duncan.coutts at worc.ox.ac.uk Mon Sep 17 08:34:42 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 17 08:34:29 2007 Subject: patch applied (cabal): Put _stub.{c|h} files under dist/ so they'll get cleaned. Fixes bug #154. Message-ID: <20070917123442.GA10598@cvs.haskell.org> Mon Sep 17 05:30:42 PDT 2007 Duncan Coutts * Put _stub.{c|h} files under dist/ so they'll get cleaned. Fixes bug #154. Only used with ghc-6.6 and later which supports the -stubdir flag. With earlier ghc versions the files still end up in the src dirs and so do not get cleaned. M ./Distribution/Simple/GHC.hs +2 From Malcolm.Wallace at cs.york.ac.uk Mon Sep 17 10:03:05 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Mon Sep 17 10:05:17 2007 Subject: cpphs and C++-style comments In-Reply-To: <200709151049.35168.sven.panne@aedion.de> References: <20070913123152.GA4408@soi.city.ac.uk> <20070914175036.GB11741@soi.city.ac.uk> <20070914210633.171c3b06.Malcolm.Wallace@cs.york.ac.uk> <200709151049.35168.sven.panne@aedion.de> Message-ID: <20070917150305.39de1f80.Malcolm.Wallace@cs.york.ac.uk> Sven Panne wrote: > On Friday 14 September 2007 22:06, Malcolm Wallace wrote: > > In particular, we could swap --strip back to mean > > what it used to mean (the current --strip-c89 behaviour), and find a > > new name for the eol-stripping flag. > > That seems to be the right way IMHO. OK, done. The new option name is --strip-eol, and --strip-c89 is gone. Regards, Malcolm From trac at galois.com Mon Sep 17 10:13:08 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 10:12:55 2007 Subject: [Hackage] #147: Replace Extension type with (newtyped?) String In-Reply-To: <054.b0f518d1f0893e5527e3012c09020cc2@localhost> References: <054.b0f518d1f0893e5527e3012c09020cc2@localhost> Message-ID: <063.43c6bc85ea158ae1eb279d5e45a6047a@localhost> #147: Replace Extension type with (newtyped?) String --------------------------+------------------------------------------------- Reporter: guest | Owner: ijones Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.4 Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux --------------------------+------------------------------------------------- Changes (by duncan): * milestone: => Cabal-1.4 * type: defect => enhancement -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 10:13:38 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 10:13:23 2007 Subject: [Hackage] #134: Clean up hooks In-Reply-To: <054.86f025cadf19a25b7e9920e8cd3b890e@localhost> References: <054.86f025cadf19a25b7e9920e8cd3b890e@localhost> Message-ID: <063.52bb003a2cf2a0e535c2648358441cc2@localhost> #134: Clean up hooks ---------------------+------------------------------------------------------ Reporter: guest | Owner: ijones Type: task | Status: new Priority: high | Milestone: Cabal-1.4 Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: very hard (<1 week) Ghcversion: 6.4.2 | Platform: Linux ---------------------+------------------------------------------------------ Changes (by duncan): * difficulty: normal => very hard (<1 week) * milestone: => Cabal-1.4 * type: defect => task -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 10:14:27 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 10:14:14 2007 Subject: [Hackage] #133: sdist and clean should never be given Maybe LocalBuildInfo In-Reply-To: <054.be70b79d2bd7c985a37b4d99a377ffaa@localhost> References: <054.be70b79d2bd7c985a37b4d99a377ffaa@localhost> Message-ID: <063.7e98ed6ea06186add699baac1eca1ebd@localhost> #133: sdist and clean should never be given Maybe LocalBuildInfo ---------------------+------------------------------------------------------ Reporter: guest | Owner: ijones Type: task | Status: new Priority: high | Milestone: Cabal-1.4 Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.4.2 | Platform: Linux ---------------------+------------------------------------------------------ Changes (by duncan): * difficulty: normal => hard (< 1 day) * milestone: => Cabal-1.4 * type: defect => task Comment: See also bug #134 -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 10:16:54 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 10:16:39 2007 Subject: [Hackage] #98: cabal assumes -x option for linking In-Reply-To: <054.870e17ae11569f495c0c5c728ffab384@localhost> References: <054.870e17ae11569f495c0c5c728ffab384@localhost> Message-ID: <063.87ebc7acdfe540e2b8b7c030c3d41bb5@localhost> #98: cabal assumes -x option for linking ----------------------------+----------------------------------------------- Reporter: maeder@tzi.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ----------------------------+----------------------------------------------- Changes (by duncan): * difficulty: normal => easy (<4 hours) * milestone: => Cabal-1.4 -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 10:21:04 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 10:20:51 2007 Subject: [Hackage] #103: feature request: preprocess files with ghc before haddock? In-Reply-To: <054.41e1ba9461fb50a67652cd44850fa53b@localhost> References: <054.41e1ba9461fb50a67652cd44850fa53b@localhost> Message-ID: <063.daf148fdd89ea6112d9f5596a23b259d@localhost> #103: feature request: preprocess files with ghc before haddock? -------------------------------+-------------------------------------------- Reporter: newsham@lava.net | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -------------------------------+-------------------------------------------- Comment (by duncan): I don't think this is possible because ghc never gives us the source code output of top level TH splices, so there's no source that we can actually pass to haddock. Perhaps with haddock 2.0 using ghc more intimately this may become possible. In either case I think it's not something we can fix in Cabal. -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 10:22:44 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 10:22:30 2007 Subject: [Hackage] #120: misleading error message from cabal when versions differ In-Reply-To: <054.f185749a0a772e0971d0aa88a881d49e@localhost> References: <054.f185749a0a772e0971d0aa88a881d49e@localhost> Message-ID: <063.898cd29eb31954014bb1389761b5e60e@localhost> #120: misleading error message from cabal when versions differ -----------------------------+---------------------------------------------- Reporter: igloo@earth.li | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Linux -----------------------------+---------------------------------------------- Changes (by duncan): * difficulty: normal => easy (<4 hours) Comment: Or perhaps it should record the version of Cabal that wrote the dist /setup-conf file and complain if they differ. -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 10:24:30 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 10:24:16 2007 Subject: [Hackage] #125: running Haddock with different options not possible In-Reply-To: <054.258c7e736fd329a1bea0317f7f9a1561@localhost> References: <054.258c7e736fd329a1bea0317f7f9a1561@localhost> Message-ID: <063.068b3572fbfeed24ce6524de748b4c69@localhost> #125: running Haddock with different options not possible -----------------------------------------+---------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -----------------------------------------+---------------------------------- Comment (by duncan): There is now a configure --haddock-options flag that passes extra flags to haddock. Does this help at all? -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 10:26:22 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 10:26:07 2007 Subject: [Hackage] #144: confusing blank line before `executable` In-Reply-To: <054.a3a3fe02612742250a486c8df72ceb25@localhost> References: <054.a3a3fe02612742250a486c8df72ceb25@localhost> Message-ID: <063.91b66657965222c525195f6282f83261@localhost> #144: confusing blank line before `executable` ---------------------------------------+------------------------------------ Reporter: Christian.Maeder@dfki.de | Owner: ijones Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux ---------------------------------------+------------------------------------ Changes (by duncan): * resolution: => fixed * status: new => closed Comment: Fixed with the new cabal file parser. The blank line is no longer required and so missing it out is not a problem. -- Ticket URL: Hackage My example project From duncan.coutts at worc.ox.ac.uk Mon Sep 17 11:16:27 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 17 11:16:12 2007 Subject: patch applied (cabal): look in odir for source and .hs files, not buildDir lbi Message-ID: <20070917151627.GA22259@cvs.haskell.org> Mon Sep 17 07:50:30 PDT 2007 Duncan Coutts * look in odir for source and .hs files, not buildDir lbi odir = buildDir lbi for the lib case, which is why it worked most of the time in testing but in the exe case it's a different dir. M ./Distribution/Simple/GHC.hs -2 +2 From trac at galois.com Mon Sep 17 11:20:27 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 11:20:12 2007 Subject: [Hackage] #154: Cabal doesn't clean "_stub" files In-Reply-To: <054.422c9b3a9d4980d442ca8287152a85ea@localhost> References: <054.422c9b3a9d4980d442ca8287152a85ea@localhost> Message-ID: <063.09326cb70525ca25554ef9b2e7ddbca5@localhost> #154: Cabal doesn't clean "_stub" files ---------------------+------------------------------------------------------ Reporter: judahj | Owner: Type: defect | Status: closed Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Mac OS ---------------------+------------------------------------------------------ Changes (by duncan): * resolution: => fixed * status: new => closed Comment: Fixed, for ghc-6.6 and later at least by using -stubdir. -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 11:23:23 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 11:23:09 2007 Subject: [Hackage] #125: running Haddock with different options not possible In-Reply-To: <054.258c7e736fd329a1bea0317f7f9a1561@localhost> References: <054.258c7e736fd329a1bea0317f7f9a1561@localhost> Message-ID: <063.acf7dbeaae86d7724297c566d951fbf3@localhost> #125: running Haddock with different options not possible -----------------------------------------+---------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -----------------------------------------+---------------------------------- Comment (by g9ks157k@acme.softbase.org): This does help, indeed. However, there is a related problem. If I want to build a documentation for developers which exposes all private things, it is not enough to run Haddock with {{{--ignore-all-exports}}}. Cabal has to run Haddock on all modules of the package, not just the modules which are exposed. Could such a feature be implemented as well? -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 11:37:59 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 11:37:46 2007 Subject: [Hackage] #125: running Haddock with different options not possible In-Reply-To: <054.258c7e736fd329a1bea0317f7f9a1561@localhost> References: <054.258c7e736fd329a1bea0317f7f9a1561@localhost> Message-ID: <063.0463f96c7fdcff536430fe0811a2e72b@localhost> #125: running Haddock with different options not possible -----------------------------------------+---------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -----------------------------------------+---------------------------------- Comment (by ross@soi.city.ac.uk): Cabal already runs haddock over all the modules, but it adds --hide options for the other modules. It would certainly be possible to add an option to turn that off. -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 11:47:59 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 11:47:44 2007 Subject: [Hackage] #125: running Haddock with different options not possible In-Reply-To: <054.258c7e736fd329a1bea0317f7f9a1561@localhost> References: <054.258c7e736fd329a1bea0317f7f9a1561@localhost> Message-ID: <063.ee5fde272089175aa46a9576855e2064@localhost> #125: running Haddock with different options not possible -----------------------------------------+---------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -----------------------------------------+---------------------------------- Comment (by duncan): So can we open a new bug for that feature request and close this bug now? -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 12:14:54 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 12:14:40 2007 Subject: [Hackage] #156: setup haddock: option to expose all modules Message-ID: <054.55d31d235c9ed9dcdd7b0598b39b601e@localhost> #156: setup haddock: option to expose all modules ----------------------------------+----------------------------------------- Reporter: ross@soi.city.ac.uk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.6 Platform: Linux | ----------------------------------+----------------------------------------- (Requested by g9ks157k@acme.softbase.org) If I want to build a documentation for developers which exposes all private things, it is not enough to run Haddock with `--ignore-all- exports`. Cabal already runs haddock over all the modules, but it adds `--hide` options for modules that are not exposed. Could there be an option to turn this off, so that all modules appear in the documentation? -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 12:16:37 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 12:16:23 2007 Subject: [Hackage] #125: running Haddock with different options not possible In-Reply-To: <054.258c7e736fd329a1bea0317f7f9a1561@localhost> References: <054.258c7e736fd329a1bea0317f7f9a1561@localhost> Message-ID: <063.538061874cb2c1edf3e0f339af8af12e@localhost> #125: running Haddock with different options not possible -----------------------------------------+---------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: ijones Type: enhancement | Status: closed Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -----------------------------------------+---------------------------------- Changes (by ross@soi.city.ac.uk): * resolution: => fixed * status: new => closed Comment: new request opened as #156 -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 12:24:16 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 12:24:03 2007 Subject: [Hackage] #104: "setup install" should configure and build if necessary In-Reply-To: <054.2d85156134065e8549dcec5f7f46139b@localhost> References: <054.2d85156134065e8549dcec5f7f46139b@localhost> Message-ID: <063.690f41f3c2f59418220e0361411a984a@localhost> #104: "setup install" should configure and build if necessary --------------------------+------------------------------------------------- Reporter: guest | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux --------------------------+------------------------------------------------- Changes (by ross@soi.city.ac.uk): * difficulty: easy (<4 hours) => normal * type: task => enhancement -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 17 12:33:02 2007 From: trac at galois.com (Hackage) Date: Mon Sep 17 12:32:50 2007 Subject: [Hackage] #156: setup haddock: option to expose all modules In-Reply-To: <054.55d31d235c9ed9dcdd7b0598b39b601e@localhost> References: <054.55d31d235c9ed9dcdd7b0598b39b601e@localhost> Message-ID: <063.44d17cee282dd6ee17626894d19a7b20@localhost> #156: setup haddock: option to expose all modules ----------------------------------+----------------------------------------- Reporter: ross@soi.city.ac.uk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux ----------------------------------+----------------------------------------- Changes (by g9ks157k@acme.softbase.org): * cc: => g9ks157k@acme.softbase.org -- Ticket URL: Hackage My example project From ross at soi.city.ac.uk Tue Sep 18 05:02:52 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Sep 18 05:02:36 2007 Subject: build-depends in old-style package descriptions In-Reply-To: <1189343923.23801.6.camel@intothevoid> References: <20070909092120.GA2652@soi.city.ac.uk> <1189343923.23801.6.camel@intothevoid> Message-ID: <20070918090252.GA3038@soi.city.ac.uk> On Sun, Sep 09, 2007 at 03:18:43PM +0200, Thomas Schilling wrote: > On Sun, 2007-09-09 at 10:21 +0100, Ross Paterson wrote: > > The build-depends field has been moved from the package level to the > > individual library and executable components. (And the new build-tools > > and pkgconfig-depends fields are similarly attached to components.) > > I'm not sure whether this is a good idea, but more specifically I > > came across this in the parser for old-style package descriptions in > > Distribution.PackageDescription: > > > > -- The 'build-depends' field was global so far. Now it's > > -- supported in each section. > > -- XXX: we actially have two options here > > -- (1) put all dependencies into the library section, if the > > -- library section would be empty, mark it as not buildable > > -- (2) duplicate all dependencies in each section, libraries > > -- and executables > > -- Right now we go with (1) > > > > Surely (1) is just wrong. Is there any reason not to do (2)? > > (1) was easier at the time. (2) should be relatively easy to implement > now, but since the current implementation works, I didn't bother so far. > I know that (1) is a rather hackish solution, but why is it "just > wrong"? (After all, it works.) Could we not just replace (deps, libfs1) = partition ((`elem` constraintFieldNames) . fName) libfs0 libfs = if null libfs1 && not (null deps) then [F (lineNo (head deps)) "buildable" "False"] else libfs1 with (deps, libfs) = partition ((`elem` constraintFieldNames) . fName) libfs0 From trac at galois.com Tue Sep 18 08:27:19 2007 From: trac at galois.com (Hackage) Date: Tue Sep 18 08:27:03 2007 Subject: [Hackage] #157: Haddock command fails when dependent documentation is not installed Message-ID: <054.a9deb51672064758eb4a7c751c2f0a38@localhost> #157: Haddock command fails when dependent documentation is not installed ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ------------------------------+--------------------------------------------- Cabal checks with ghc-pkg for where the .haddock file of dependent packages should be. However even though ghc-pkg says it's there, it very often isn't there. In this case we still ask haddock to use it, and haddock justifiably complains. Cabal should check that the .haddock file actually exists. If it does not, Cabal should warn that links to this dependent package will not be generated because the docs for this dependent package are not installed. It should then not tell haddock to use that package. Current behavior: {{ $ runghc Setup.lhs haddock Preprocessing library bytestring-0.9... Running Haddock for bytestring-0.9... haddock: /usr/share/doc/ghc-6.4.2/html/libraries/base/base.haddock: openBinaryFile: does not exist (No such file or directory) }} Desired behavior: {{ $ runghc Setup.lhs haddock Preprocessing library bytestring-0.9... Running Haddock for bytestring-0.9... Warning: Documentation for package base is not installed. No links will be generated. Documentation created: dist/doc/html/bytestring/index.html }} Or something like that, I'm sure someone can think of a clear friendly warning message This should be an easy bug for some new Cabal hacker to have a go at. It should just require modifying makeReadInterface in the Distribution.Simple.Haddock module. -- Ticket URL: Hackage My example project From Malcolm.Wallace at cs.york.ac.uk Wed Sep 19 08:25:17 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Sep 19 08:37:25 2007 Subject: cpphs and C++-style comments In-Reply-To: References: <20070913123152.GA4408@soi.city.ac.uk> <20070914175036.GB11741@soi.city.ac.uk> <20070914210633.171c3b06.Malcolm.Wallace@cs.york.ac.uk> <200709151049.35168.sven.panne@aedion.de> <20070917150305.39de1f80.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20070919132517.10d887ab.Malcolm.Wallace@cs.york.ac.uk> Benjamin Franksen wrote: > > OK, done. The new option name is --strip-eol, and --strip-c89 is > > gone. > > I'd rather name the flag --strip-cc or something like that, indicating > that it refers to C++ comments (--strip-cpp might be misleading, though). How about --strip-c++ then? Regards, Malcolm From duncan.coutts at worc.ox.ac.uk Thu Sep 20 11:19:10 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 20 11:18:46 2007 Subject: patch applied (cabal): Correct the verbosity range in the "--help" text Message-ID: <20070920151910.GA2043@cvs.haskell.org> Sun Sep 16 19:44:16 PDT 2007 Duncan Coutts * Correct the verbosity range in the "--help" text The correct range in 0--3, not 0--2 or 0--5 M ./Distribution/Simple/Setup.hs -1 +1 M ./Distribution/Simple/SetupWrapper.hs -1 +2 From duncan.coutts at worc.ox.ac.uk Thu Sep 20 11:19:12 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 20 11:18:48 2007 Subject: patch applied (cabal): Put setup program and setup .o/.hi files into dist/setup Message-ID: <20070920151912.GA2073@cvs.haskell.org> Sun Sep 16 19:49:07 PDT 2007 Duncan Coutts * Put setup program and setup .o/.hi files into dist/setup That way they get cleaned automatically and do not clutter the top dir. M ./Distribution/Simple/SetupWrapper.hs -10 +18 From duncan.coutts at worc.ox.ac.uk Thu Sep 20 11:19:13 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 20 11:18:50 2007 Subject: patch applied (cabal): Pass on all the cabal-setup options to cabal, not just unrecognised ones Message-ID: <20070920151913.GA2090@cvs.haskell.org> Sun Sep 16 19:51:21 PDT 2007 Duncan Coutts * Pass on all the cabal-setup options to cabal, not just unrecognised ones So for example -v and -w get passed on rather than swallowed by cabal-setup itself. M ./Distribution/Simple/SetupWrapper.hs -5 +4 From duncan.coutts at worc.ox.ac.uk Thu Sep 20 11:19:14 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 20 11:18:53 2007 Subject: patch applied (cabal): Note in .cabal file that we're using a custom build-type Message-ID: <20070920151914.GA2104@cvs.haskell.org> Sun Sep 16 20:39:59 PDT 2007 Duncan Coutts * Note in .cabal file that we're using a custom build-type M ./Cabal.cabal +3 From duncan.coutts at worc.ox.ac.uk Thu Sep 20 11:19:16 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Sep 20 11:18:54 2007 Subject: patch applied (cabal): Move expensive conviguration actions inside branch where they're used Message-ID: <20070920151916.GA2118@cvs.haskell.org> Mon Sep 17 01:58:34 PDT 2007 Duncan Coutts * Move expensive conviguration actions inside branch where they're used We only need to configure the compiler and resolve any "Cabal-Version:" dependency when we're actually going to compile the Setup.hs program. We can otherwise save time by not calling ghc and ghc-pkg unnecessarily. (I only noticed this because I've got >150 registered packages which causes ghc and ghc-pkg to be very slow to start.) M ./Distribution/Simple/SetupWrapper.hs -6 +4 From igloo at earth.li Thu Sep 20 19:06:14 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 20 19:05:51 2007 Subject: patch applied (cabal-branches/cabal-1.2): Display warning if sections are found within other sections. This Message-ID: <20070920230614.GA17093@cvs.haskell.org> Thu Sep 13 06:13:46 PDT 2007 Thomas Schilling * Display warning if sections are found within other sections. This most likely represents an error (missing colon after field name). This patch is only for the Cabal 1.2 branch; the proper fix requires more complex changes. M ./Distribution/PackageDescription.hs -4 +11 From igloo at earth.li Thu Sep 20 19:06:16 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 20 19:05:53 2007 Subject: patch applied (cabal-branches/cabal-1.2): Add a Distribution.Setup module that re-exports Distribution.Simple.Setup Message-ID: <20070920230616.GA17113@cvs.haskell.org> Thu Sep 20 05:11:25 PDT 2007 Duncan Coutts * Add a Distribution.Setup module that re-exports Distribution.Simple.Setup Many Setup.hs files import Distribution.Setup so this unbreaks them. It's marked DEPRECATED so will generate a warning for scripts that use it. This patch is only going to the cabal-1.2 branch, not HEAD. M ./Cabal.cabal +1 A ./Distribution/Setup.hs From igloo at earth.li Thu Sep 20 19:06:17 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 20 19:05:56 2007 Subject: patch applied (cabal-branches/cabal-1.2): Remove some now-unecessary cleaning that causes problems for haskell-src Message-ID: <20070920230617.GA17127@cvs.haskell.org> Thu Sep 20 13:32:57 PDT 2007 Ian Lynagh * Remove some now-unecessary cleaning that causes problems for haskell-src The code that removes .hs files in the source tree generated from .y files had a comment: XXX: This is actually no longer necessary, but we keep it, so that clean works correctly on packages built with an older version of Cabal This was causing problems for source distributions that include such generated files (including haskell-src in extralibs). M ./Distribution/Simple.hs -5 +1 From duncan.coutts at worc.ox.ac.uk Fri Sep 21 15:35:15 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Sep 21 15:34:49 2007 Subject: patch applied (cabal): Remove some now-unecessary cleaning that causes problems for haskell-src Message-ID: <20070921193515.GA8840@cvs.haskell.org> Thu Sep 20 13:32:57 PDT 2007 Ian Lynagh * Remove some now-unecessary cleaning that causes problems for haskell-src The code that removes .hs files in the source tree generated from .y files had a comment: XXX: This is actually no longer necessary, but we keep it, so that clean works correctly on packages built with an older version of Cabal This was causing problems for source distributions that include such generated files (including haskell-src in extralibs). M ./Distribution/Simple.hs -5 +1 From duncan.coutts at worc.ox.ac.uk Fri Sep 21 15:35:17 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Sep 21 15:34:52 2007 Subject: patch applied (cabal): Add a boring file Message-ID: <20070921193517.GA8860@cvs.haskell.org> Thu Sep 13 13:35:50 PDT 2007 Ian Lynagh * Add a boring file A ./.darcs-boring From duncan.coutts at worc.ox.ac.uk Sat Sep 22 14:12:39 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Sep 22 14:12:08 2007 Subject: patch applied (cabal): Fix pre-processing for executables Message-ID: <20070922181239.GA31496@cvs.haskell.org> Sat Sep 22 03:54:14 PDT 2007 Duncan Coutts * Fix pre-processing for executables The pre-processed files should go into the exe's build dir, not the lib's build dir. Also pre-process main modules, fixing bug #14. M ./Distribution/Simple/GHC.hs -1 +1 M ./Distribution/Simple/PreProcess.hs -2 +7 From trac at galois.com Sat Sep 22 14:16:44 2007 From: trac at galois.com (Hackage) Date: Sat Sep 22 14:16:12 2007 Subject: [Hackage] #14: allow preprocessing for Main modules In-Reply-To: <054.f8d218cc39ca5cccf8817bcd8638dc4c@localhost> References: <054.f8d218cc39ca5cccf8817bcd8638dc4c@localhost> Message-ID: <063.fccb86aabf3c5fedafda6c33b4388ab7@localhost> #14: allow preprocessing for Main modules ---------------------+------------------------------------------------------ Reporter: ijones | Owner: duncan Type: defect | Status: assigned Priority: high | Milestone: Cabal-1.2 Component: Cabal | Version: 1.1.3 Severity: normal | Resolution: Keywords: | Difficulty: easy Ghcversion: 6.2.1 | Platform: Linux ---------------------+------------------------------------------------------ Changes (by duncan): * ghcversion: => 6.2.1 * platform: => Linux * status: new => assigned * owner: ijones => duncan Comment: This second patch has been committed to Cabal HEAD. Perhaps someone can test and confirm this as I've only tested one small example. One actually needs to say: {{{ Executable: Foo Main-is: Main.hs }}} and it'll look for any suitable file that can be pre-processed into {{{Main.hs}}}, like {{{Main.hsc}}} for example. -- Ticket URL: Hackage My example project From pgavin at gmail.com Sat Sep 22 14:20:12 2007 From: pgavin at gmail.com (Peter Gavin) Date: Sat Sep 22 14:19:41 2007 Subject: cabal dependencies patch Message-ID: <37df87420709221120r7328b39ay2a8b1e3cbdcb5312@mail.gmail.com> Duncan requested that I post a more up-to-date version of the dependencies based build for the upcoming Hackathon. It still needs some work, but the bright side is that it's a drop-in replacement for the current build system. I guess what still needs to be done is: * Hugs, NHC, etc. I don't really use anything but GHC. * Executables - I'm thinking about writing out an in-place config file and just using ghc --make -hide-all-packages -package-conf ... -package ... * Standardize some kind of structure for the build directories. It's currently pretty ad-hoc. * Documentation - I meant to do this but I've been pretty busy the last couple weeks. The code is pretty straightforward, though. * Finally, it needs to eventually be better integrated with the rest of cabal. Since I decided to do it without modifying any of the other cabal sources, I end up duplicating a lot of code in places. Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: cabal.dependencies.20070922.dpatch.bz2 Type: application/x-bzip2 Size: 11667 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070922/c2619463/cabal.dependencies.20070922.dpatch.bin From igloo at earth.li Sun Sep 23 09:23:35 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Sep 23 09:23:02 2007 Subject: patch applied (cabal-branches/cabal-1.2): Fix warnings Message-ID: <20070923132335.GA15844@cvs.haskell.org> Sun Sep 23 05:29:21 PDT 2007 Ian Lynagh * Fix warnings M ./Distribution/Simple.hs -2 +1 From duncan.coutts at worc.ox.ac.uk Mon Sep 24 10:38:50 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 24 10:38:14 2007 Subject: patch applied (cabal): Fix warnings Message-ID: <20070924143850.GA6378@cvs.haskell.org> Sun Sep 23 05:29:21 PDT 2007 Ian Lynagh * Fix warnings M ./Distribution/Simple.hs -2 +1 From duncan.coutts at worc.ox.ac.uk Mon Sep 24 10:38:51 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Sep 24 10:38:16 2007 Subject: patch applied (cabal): Don't generate links when dependent docs not installed. Fixes bug #157. Message-ID: <20070924143851.GA6398@cvs.haskell.org> Mon Sep 24 07:25:20 PDT 2007 Duncan Coutts * Don't generate links when dependent docs not installed. Fixes bug #157. Generates a warning rather than failing as before. M ./Distribution/Simple/Haddock.hs -6 +11 From trac at galois.com Mon Sep 24 10:40:39 2007 From: trac at galois.com (Hackage) Date: Mon Sep 24 10:40:03 2007 Subject: [Hackage] #157: Haddock command fails when dependent documentation is not installed In-Reply-To: <054.a9deb51672064758eb4a7c751c2f0a38@localhost> References: <054.a9deb51672064758eb4a7c751c2f0a38@localhost> Message-ID: <063.721f782bcdddcb0ae48a449313c6bca0@localhost> #157: Haddock command fails when dependent documentation is not installed ---------------------+------------------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.4.2 | Platform: Linux ---------------------+------------------------------------------------------ Changes (by duncan): * resolution: => fixed * status: new => closed -- Ticket URL: Hackage My example project From trac at galois.com Mon Sep 24 10:40:39 2007 From: trac at galois.com (Hackage) Date: Mon Sep 24 10:40:05 2007 Subject: [Hackage] #14: allow preprocessing for Main modules In-Reply-To: <054.f8d218cc39ca5cccf8817bcd8638dc4c@localhost> References: <054.f8d218cc39ca5cccf8817bcd8638dc4c@localhost> Message-ID: <063.3cd70a1fc809343ee7dfd4d2f7b2daca@localhost> #14: allow preprocessing for Main modules ---------------------+------------------------------------------------------ Reporter: ijones | Owner: duncan Type: defect | Status: closed Priority: high | Milestone: Cabal-1.2 Component: Cabal | Version: 1.1.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy Ghcversion: 6.2.1 | Platform: Linux ---------------------+------------------------------------------------------ Changes (by duncan): * resolution: => fixed * status: assigned => closed -- Ticket URL: Hackage My example project From nominolo at googlemail.com Mon Sep 24 15:53:16 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Sep 24 15:52:53 2007 Subject: RFC: Extended version-range descriptions for Cabal Message-ID: <1190663596.6247.30.camel@intothevoid> Hi librarians, I'd like to propose a an extension to Cabal's dependency description syntax. Cabal currently supports version range descriptions using the unary operators >, >=, <, <=, ==, and binary operators && and ||. This can lead to rather awkward descriptions of common version ranges, for example, base >= 1 && < 2 and could lead to subtle errors like base > 1 && < 2 or base >= 1 && <= 2 I therefore propose two extensions. Both are just syntactic sugar. (1) Wildcards: 1.* ~~> >= 1 && < 2 in general m.n.o.* ~~> >= m.n.o && < m.n.(o+1) Note, that the translation is not ">= 1.0 && < 2", because that would exclude version "1", as [1] < [1,0] == True. (2) Ranges: 1 - 2.1 ~~> >= 1 && <= 2.1 in general m - n ~~> >= m && <= n If the upper limit is supposed to be exclusive, this can be combined with (1): 1 - 2.0.* ~~> >= 1 && < 2.1 A possible alternatve syntax (subsuming both (1) and (2)) could be: [1, 2.1] ~~> >= 1 && <= 2.1 [1, 2.1) ~~> >= 1 && < 2.1 Although this syntax is closer to mathematical notation, I prefer the former for it is more explicit and more similar to common conventions used in other languages/package systems (an less scary scary to non-math-aficiados). I'd like include this into Cabal-1.2 which is scheduled with the next ghc release, so it can fearlessly be used when getting packages ready for GC 6.8.1. Please comment/vote. Thanks, / Thomas From bos at serpentine.com Mon Sep 24 16:06:43 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon Sep 24 16:06:07 2007 Subject: RFC: Extended version-range descriptions for Cabal In-Reply-To: <1190663596.6247.30.camel@intothevoid> References: <1190663596.6247.30.camel@intothevoid> Message-ID: <46F818D3.70701@serpentine.com> Thomas Schilling wrote: > (1) Wildcards: > > 1.* ~~> >= 1 && < 2 > > in general > > m.n.o.* ~~> >= m.n.o && < m.n.(o+1) I like this. > (2) Ranges: > > 1 - 2.1 ~~> >= 1 && <= 2.1 > > in general > > m - n ~~> >= m && <= n > > If the upper limit is supposed to be exclusive, this can be combined > with (1): > > 1 - 2.0.* ~~> >= 1 && < 2.1 I like this, too, though maybe "to" instead of "-" would be a more readable token to use. > A possible alternatve syntax (subsuming both (1) and (2)) could be: > > [1, 2.1] ~~> >= 1 && <= 2.1 > [1, 2.1) ~~> >= 1 && < 2.1 This is too prone to fencepost errors due to the ease of getting the parens wrong. Also, interval notation isn't widely enough used that people will readily remember which kind of paren means what. References: <1190663596.6247.30.camel@intothevoid> <46F818D3.70701@serpentine.com> Message-ID: <404396ef0709241336n1fd188dax119feab0f71ac542@mail.gmail.com> Hi > > m.n.o.* ~~> >= m.n.o && < m.n.(o+1) > > I like this. Me too. > > m - n ~~> >= m && <= n I would much prefer m .. n as the syntax, as that is the syntax for ranges in Haskell. Thanks Neil From igloo at earth.li Mon Sep 24 17:02:28 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Sep 24 17:01:49 2007 Subject: RFC: Extended version-range descriptions for Cabal In-Reply-To: <1190663596.6247.30.camel@intothevoid> References: <1190663596.6247.30.camel@intothevoid> Message-ID: <20070924210228.GA26538@matrix.chaos.earth.li> On Mon, Sep 24, 2007 at 09:53:16PM +0200, Thomas Schilling wrote: > > can lead to rather awkward descriptions of common version ranges, for > example, > > base >= 1 && < 2 I don't think anything more is needed, but... > (1) Wildcards: > > 1.* ~~> >= 1 && < 2 > > in general > > m.n.o.* ~~> >= m.n.o && < m.n.(o+1) I have no objections to this. > Note, that the translation is not ">= 1.0 && < 2", because that would > exclude version "1", as [1] < [1,0] == True. I'm not convinced that that isn't a bug. > (2) Ranges: > > 1 - 2.1