From naur at post11.tele.dk Sun Oct 7 09:07:12 2007 From: naur at post11.tele.dk (naur@post11.tele.dk) Date: Sun Oct 7 09:05:54 2007 Subject: Patch to fix processing of shared options Message-ID: <20071007130712.MKLW28517.fep34.mail.dk@post.tele.dk> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: fix-processing-of-shared-options.dpatch Type: application/octet-stream Size: 45802 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20071007/e36c2568/fix-processing-of-shared-options-0001.obj From naur at post11.tele.dk Sun Oct 7 09:28:33 2007 From: naur at post11.tele.dk (naur@post11.tele.dk) Date: Sun Oct 7 09:27:13 2007 Subject: A second fix to the processing of shared options Message-ID: <20071007132832.MTXH28517.fep34.mail.dk@post.tele.dk> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: fix-processing-of-shared-options_2.dpatch Type: application/octet-stream Size: 45687 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20071007/33bacfea/fix-processing-of-shared-options_2-0001.obj From bringert at cs.chalmers.se Mon Oct 8 17:16:26 2007 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Mon Oct 8 17:14:18 2007 Subject: Push patches for cabal-install to cabal-1.2 Message-ID: <781FA0AD-8CBE-4C66-B2A5-C248CEFAF0B9@cs.chalmers.se> These two patches in cabal head should be pushed to the 1.2 branch to make cabal-install work with 1.2. We really want cabal-install to be buildable on GHC 6.8.1. I haven't done it myself since I don't have the setup for validating GHC stable patches at the moment. Sat Oct 6 10:33:54 CEST 2007 bjorn@bringert.net * Rename parseDescription to parsePackageDescription. This should be pushed to cabal-1.2 to make cabal-install work with 1.2. Fri Oct 5 12:45:54 CEST 2007 bjorn@bringert.net * Expose parseDescription. /Bj?rn From ndmitchell at gmail.com Wed Oct 10 13:01:29 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Oct 10 13:00:04 2007 Subject: [Haskell-cafe] Adding GLUT package to WinHugs In-Reply-To: <470D02D0.20807@telenet.be> References: <470D02D0.20807@telenet.be> Message-ID: <404396ef0710101001w4c972f0cpa5e7d6d88f5670b6@mail.gmail.com> Hi Peter, > Also typing runhugs Setup.hs configure fails with > > runhugs: Error occurred > ERROR "c:\program > files\winhugs\packages\base\Text\ParserCombinators\ReadP.hs":156 > - Syntax error in type expression (unexpected `.') This is because Cabal gets it wrong. You need to type runhugs -98 Setup configure. There is an easy fix, which is for the Cabal developers to always use the bundled ReadP rather than the library one. I talked to Duncan about this in Germany, and he said he'd fix it :-) Thanks Neil From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:06 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:22 2007 Subject: patch applied (cabal-branches/cabal-1.2): Haddock comment for the available dependencies argument to finalizePackageDescription. Message-ID: <20071015191406.GA24745@haskell.galois.com> Thu Oct 4 06:45:44 PDT 2007 bjorn@bringert.net * Haddock comment for the available dependencies argument to finalizePackageDescription. M ./Distribution/PackageDescription.hs -1 +2 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:07 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:24 2007 Subject: patch applied (cabal-branches/cabal-1.2): Fix GenericPrackageDescription pretty printing to make it parsable. It still does not include all information. Message-ID: <20071015191407.GA24761@haskell.galois.com> Fri Oct 5 03:25:55 PDT 2007 bjorn@bringert.net * Fix GenericPrackageDescription pretty printing to make it parsable. It still does not include all information. M ./Distribution/Configuration.hs -1 +1 M ./Distribution/PackageDescription.hs -7 +4 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:09 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:25 2007 Subject: patch applied (cabal-branches/cabal-1.2): Expose parseDescription. Message-ID: <20071015191409.GA24777@haskell.galois.com> Fri Oct 5 03:45:54 PDT 2007 bjorn@bringert.net * Expose parseDescription. M ./Distribution/PackageDescription.hs +1 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:03 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:25 2007 Subject: patch applied (cabal-branches/cabal-1.2): Be more fuzzy with os, arch and impl matching in conditions. Fixes bug #158. Message-ID: <20071015191403.GA24723@haskell.galois.com> Tue Sep 25 06:26:08 PDT 2007 Duncan Coutts * Be more fuzzy with os, arch and impl matching in conditions. Fixes bug #158. Do all the comparisons case insensitively and add some OS aliases so that if os(windows) works if the System.Info.os is actually "mingw32". M ./Distribution/Configuration.hs -3 +11 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:10 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:27 2007 Subject: patch applied (cabal-branches/cabal-1.2): Rename parseDescription to parsePackageDescription. Message-ID: <20071015191410.GA24793@haskell.galois.com> Sat Oct 6 01:33:54 PDT 2007 bjorn@bringert.net * Rename parseDescription to parsePackageDescription. This should be pushed to cabal-1.2 to make cabal-install work with 1.2. M ./Distribution/PackageDescription.hs -10 +10 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:13 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:29 2007 Subject: patch applied (cabal-branches/cabal-1.2): Use -O2 for compiling .c files when we configure --enable-optimization Message-ID: <20071015191413.GA24825@haskell.galois.com> Thu Oct 11 15:36:07 PDT 2007 Duncan Coutts * Use -O2 for compiling .c files when we configure --enable-optimization Seems a reasonable default behaviour. M ./Distribution/Simple/GHC.hs +1 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:12 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:29 2007 Subject: patch applied (cabal-branches/cabal-1.2): Remove commented-out code. Message-ID: <20071015191412.GA24809@haskell.galois.com> Sat Oct 6 01:36:15 PDT 2007 bjorn@bringert.net * Remove commented-out code. Push to 1.2. M ./Distribution/PackageDescription.hs -2 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:16 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:31 2007 Subject: patch applied (cabal-branches/cabal-1.2): Add logging functions notice, info, debug functions and use them consistently Message-ID: <20071015191416.GA24857@haskell.galois.com> Fri Oct 12 04:32:37 PDT 2007 Duncan Coutts * Add logging functions notice, info, debug functions and use them consistently We previously had this kind of code all over the place: > when (verbosity >= verbose) > (putStrLn "some message") We now replace that with: > info verbosity "some message" Much nicer. M ./Distribution/PackageDescription.hs -3 +2 M ./Distribution/Simple.hs -5 +4 M ./Distribution/Simple/Configure.hs -35 +29 M ./Distribution/Simple/GHC.hs -10 +7 M ./Distribution/Simple/Haddock.hs -11 +10 M ./Distribution/Simple/Hugs.hs -5 +4 M ./Distribution/Simple/Install.hs -8 +7 M ./Distribution/Simple/JHC.hs -5 +3 M ./Distribution/Simple/PreProcess.hs -2 +1 M ./Distribution/Simple/Program.hs -14 +11 M ./Distribution/Simple/Register.hs -3 +2 M ./Distribution/Simple/SrcDist.hs -6 +5 M ./Distribution/Simple/Utils.hs -12 +43 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:15 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:31 2007 Subject: patch applied (cabal-branches/cabal-1.2): Update documentation on configurations Message-ID: <20071015191415.GA24841@haskell.galois.com> Thu Oct 11 18:53:38 PDT 2007 Duncan Coutts * Update documentation on configurations Describe the new syntax and make variuous changes to the description of the meaning. M ./doc/Cabal.xml -123 +170 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:18 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:33 2007 Subject: patch applied (cabal-branches/cabal-1.2): Pass -w -v0 to ghc when compiling Setup.{lhs, hs} in SetupWrapper when verbosity == silent. Message-ID: <20071015191418.GA24873@haskell.galois.com> Sat Oct 13 14:48:20 PDT 2007 bjorn@bringert.net * Pass -w -v0 to ghc when compiling Setup.{lhs,hs} in SetupWrapper when verbosity == silent. M ./Distribution/Simple/SetupWrapper.hs -1 +7 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:19 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:34 2007 Subject: patch applied (cabal-branches/cabal-1.2): Change --verbosity= option of SetupWrapper (cabal-setup) to --verbose=, since that is what the rest of Cabal uses. Message-ID: <20071015191419.GA24889@haskell.galois.com> Sat Oct 13 14:56:17 PDT 2007 bjorn@bringert.net * Change --verbosity= option of SetupWrapper (cabal-setup) to --verbose=, since that is what the rest of Cabal uses. M ./Distribution/Simple/SetupWrapper.hs -1 +1 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:21 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:37 2007 Subject: patch applied (cabal-branches/cabal-1.2): Pass -c (silent create) to ar when verbosity < normal. Message-ID: <20071015191421.GA24905@haskell.galois.com> Sat Oct 13 15:09:06 PDT 2007 bjorn@bringert.net * Pass -c (silent create) to ar when verbosity < normal. M ./Distribution/Simple/GHC.hs -2 +5 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 15:14:22 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 15:12:38 2007 Subject: patch applied (cabal-branches/cabal-1.2): Move ghcVerbosity function into GHC module to share code Message-ID: <20071015191422.GA24921@haskell.galois.com> Sun Oct 14 09:57:30 PDT 2007 Duncan Coutts * Move ghcVerbosity function into GHC module to share code M ./Distribution/Simple/GHC.hs -4 +9 M ./Distribution/Simple/SetupWrapper.hs -7 +2 From duncan.coutts at worc.ox.ac.uk Mon Oct 15 17:10:40 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 17:06:08 2007 Subject: [Haskell-cafe] Adding GLUT package to WinHugs In-Reply-To: <404396ef0710101001w4c972f0cpa5e7d6d88f5670b6@mail.gmail.com> References: <470D02D0.20807@telenet.be> <404396ef0710101001w4c972f0cpa5e7d6d88f5670b6@mail.gmail.com> Message-ID: <1192482640.9844.149.camel@localhost> Ross, What do you reckon we should do? We could change: #if __GLASGOW_HASKELL__ >= 603 || __HUGS__ import Text.ParserCombinators.ReadP hiding (ReadP) import qualified Text.ParserCombinators.ReadP as ReadP ... to drop the || __HUGS__ and have hugs always use the bundled H98 ReadP, or we can continue to use the non-H98 one that comes with hugs. This has the obvious downside that users need to know to run: runhugs -98 Setup.hs which is a bit unfortunate. Duncan On Wed, 2007-10-10 at 18:01 +0100, Neil Mitchell wrote: > Hi Peter, > > > Also typing runhugs Setup.hs configure fails with > > > > runhugs: Error occurred > > ERROR "c:\program > > files\winhugs\packages\base\Text\ParserCombinators\ReadP.hs":156 > > - Syntax error in type expression (unexpected `.') > > This is because Cabal gets it wrong. You need to type runhugs -98 > Setup configure. There is an easy fix, which is for the Cabal > developers to always use the bundled ReadP rather than the library > one. I talked to Duncan about this in Germany, and he said he'd fix it > :-) From trac at galois.com Mon Oct 15 17:09:36 2007 From: trac at galois.com (Hackage) Date: Mon Oct 15 17:07:55 2007 Subject: [Hackage] #155: show . readPackageDescription /= id In-Reply-To: <062.7ab68407296e577f3ca8026fe40bb35d@localhost> References: <062.7ab68407296e577f3ca8026fe40bb35d@localhost> Message-ID: <071.9a775114d9c07d735f411e759bd55f0e@localhost> #155: show . readPackageDescription /= id ----------------------------------------+----------------------------------- Reporter: kolmodin@dtek.chalmers.se | Owner: nominolo Type: defect | Status: assigned Priority: normal | Milestone: Component: Cabal | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux ----------------------------------------+----------------------------------- Comment (by duncan): This works now I think. Can someone check it and close this bug please. -- Ticket URL: Hackage Hackage: Cabal and related projects From ross at soi.city.ac.uk Mon Oct 15 19:31:54 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Oct 15 19:30:16 2007 Subject: [Haskell-cafe] Adding GLUT package to WinHugs In-Reply-To: <1192482640.9844.149.camel@localhost> References: <470D02D0.20807@telenet.be> <404396ef0710101001w4c972f0cpa5e7d6d88f5670b6@mail.gmail.com> <1192482640.9844.149.camel@localhost> Message-ID: <20071015233123.GA2716@soi.city.ac.uk> On Mon, Oct 15, 2007 at 10:10:40PM +0100, Duncan Coutts wrote: > What do you reckon we should do? We could change: > > #if __GLASGOW_HASKELL__ >= 603 || __HUGS__ > > import Text.ParserCombinators.ReadP hiding (ReadP) > import qualified Text.ParserCombinators.ReadP as ReadP > ... > > to drop the || __HUGS__ and have hugs always use the bundled H98 ReadP, > or we can continue to use the non-H98 one that comes with hugs. This has > the obvious downside that users need to know to run: > > runhugs -98 Setup.hs > > which is a bit unfortunate. On the other hand, changing the ReadP in Cabal would leave the parsers in Cabal incompatible with other ReadP parsers. From duncan.coutts at worc.ox.ac.uk Mon Oct 15 21:03:23 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Oct 15 20:58:48 2007 Subject: [Haskell-cafe] Adding GLUT package to WinHugs In-Reply-To: <20071015233123.GA2716@soi.city.ac.uk> References: <470D02D0.20807@telenet.be> <404396ef0710101001w4c972f0cpa5e7d6d88f5670b6@mail.gmail.com> <1192482640.9844.149.camel@localhost> <20071015233123.GA2716@soi.city.ac.uk> Message-ID: <1192496603.9844.157.camel@localhost> On Tue, 2007-10-16 at 00:31 +0100, Ross Paterson wrote: > On Mon, Oct 15, 2007 at 10:10:40PM +0100, Duncan Coutts wrote: > > What do you reckon we should do? We could change: > > > > #if __GLASGOW_HASKELL__ >= 603 || __HUGS__ > > > > import Text.ParserCombinators.ReadP hiding (ReadP) > > import qualified Text.ParserCombinators.ReadP as ReadP > > ... > > > > to drop the || __HUGS__ and have hugs always use the bundled H98 ReadP, > > or we can continue to use the non-H98 one that comes with hugs. This has > > the obvious downside that users need to know to run: > > > > runhugs -98 Setup.hs > > > > which is a bit unfortunate. > > On the other hand, changing the ReadP in Cabal would leave the parsers > in Cabal incompatible with other ReadP parsers. We already have this problem. If people import the 'standard' ReadP and use it with Cabal then we get type errors on systems where we use the bundled one. We've already had to change a few imports of Text.ParserCombinators.ReadP to Distribution.Compat.ReadP, eg in cabal-install. The same applies to any Setup script that uses Cabal's parser functions. Duncan From duncan.coutts at worc.ox.ac.uk Tue Oct 16 05:46:26 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Oct 16 05:41:54 2007 Subject: CPP confusion Message-ID: <1192527986.9844.175.camel@localhost> All, There seems to me to be a great deal of confusion with CPP options in Haskell land. We apply the same cpp options to C code and to Haskell code, and there are other tools like pre-processors which make things even more confusing. The latest thing I've stumbled over is HsUnix.h in ghc-6.8. This header file is for defines to use when pre-processing Haskell code. It used to live in the global $GHCLIBDIR/include but now lives in the include dir for the unix package. This is probably the right thing to do, however... How do packages that want to use this include actually use it? If they #include it directly in a .hs file then it'll work since ghc -package unix adds the unix package's include dir to the search path. But what if someone needs to use it in a .hsc file? Well, then it does not work. It does not work because Cabal does not pass these include directories to hsc2hs, since we've relied on ghc to do that. But obviously that does not work for hsc2hs. As it happens the fork of hsc2hs that ghc comes bundled with uses ghc as it's C compiler, so we could in fact pass hsc2hs --cflag=-package --cflag=unix then it does work because hsc2hs ends up passing ghc -package unix and then ghc adds the unix's include dir to the search path when it goes on to call gcc to actually compile the C code. Yay, for many layers of confusion. So what is the solution? We could take advantage of the fact that we know that hsc2hs really uses ghc as it's C compiler and change the flags we pass it when we happen to be building with ghc. On the other hand this all becomes non-portable. In fact this totally relies on a package database to remember what search directories to use when pre-processing dependent packages. In other words it only has a chance of working with ghc at the moment, or nhc in future if/when it implements a package database. What to do? Short and long term suggestions please. Duncan From simonmarhaskell at gmail.com Tue Oct 16 08:08:49 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Oct 16 08:07:12 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <200710162354.37812.dm.maillists@gmail.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> Message-ID: <4714A9D1.8070501@microsoft.com> Several good points have been raised in this thread, and while I might not agree with everything, I think we can all agree on the goal: things shouldn't break so often. So rather than keep replying to individual points, I'd like to make some concrete proposals so we can make progress. 1. Document the version numbering policy. We should have done this earlier, but we didn't. The proposed policy, for the sake of completeness is: x.y where: x changes ==> API changed x constant but y changes ==> API extended only x and y constant ==> API is identical further sub-versions may be added after the x.y, their meaning is package-defined. Ordering on versions is lexicographic, given multiple versions that satisfy a dependency Cabal will pick the latest. 2. Precise dependencies. As suggested by various people in this thread: we change the convention so that dependencies must specify a single x.y API version, or a range of versions with an upper bound. Cabal or Hackage can refuse to accept packages that don't follow this convention (perhaps Hackage is a better place to enforce it, and Cabal should just warn, I'm not sure). Yes, earlier I argued that not specifying precise dependencies allows some packages to continue working even when dependencies change, and that having precise dependencies means that all packages are guaranteed to break when base is updated. However, I agree that specifying precise dependencies is ultimately the right thing, we'll get better errors when things break, There's lots more to discuss, but I think the above 2 proposals are a step in the right direction, agreed? Cheers, Simon From simonmarhaskell at gmail.com Tue Oct 16 08:21:03 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Oct 16 08:19:21 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <012701c80fe6$df9fddb0$5b238351@cr3lt> References: <20071014140922.GA25871@matrix.chaos.earth.li><00fd01c80e8a$4c34e5f0$21358351@cr3lt><47133895.2090301@gmail.com> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <012701c80fe6$df9fddb0$5b238351@cr3lt> Message-ID: <4714ACAF.2040907@microsoft.com> Claus Reinke wrote: >>> - if you provide a 'base' configuration that pulls in the stuff that >>> used to be in base, the package will work >> >> I don't know of a way to do that. The name of the package is baked >> into the object files at compile time, so you can't use the same >> compiled module in more than one package. > > i've been wrong about this before, so check before you believe,-) but > here is a hack i arrived at the last time we discussed this: > > [using time:Data.Time as a small example; ghc-6.6.1] > > 1. create, build, and install a package QTime, with default Setup.hs ... > 2. create, build, and install a package Time2, with default Setup.hs ... > 3. write and build a client module Ok, when I said above "I don't know a way to do that", I really meant there's no way to do it by modifying the package database alone, which I think is what Udo was after. Your scheme does work, and you have discovered how to make a package that re-exports modules from other packages (I made a similar discovery recently when looking into how to add support to Cabal for this). As you can see, it's rather cumbersome, in that you need an extra dummy package, and two stub modules for each module to be re-exported. One way to make this easier is to add a little extension to GHC, one that we've discussed before: module Data.Time (module Base1.Data.Time) where import "base-1.0" Data.Time as Base1.Data.Time the extension is the "base-1.0" package qualifier on the import, which GHC very nearly supports (only the syntax is missing). Now you don't need the dummy package, and only one stub module per module to be re-exported. Cabal could generate these automatically, given some appropriate syntax. Furthermore, this is better than doing something at the package level, because you're not stuck with module granularity, you can re-export just parts of a module, which is necessary if you're trying to recreate an old version of an API. I was going to propose this at some point. Comments? Cheers, Simon From simonmarhaskell at gmail.com Tue Oct 16 08:44:44 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Oct 16 08:43:11 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <4714ACAF.2040907@microsoft.com> References: <20071014140922.GA25871@matrix.chaos.earth.li><00fd01c80e8a$4c34e5f0$21358351@cr3lt><47133895.2090301@gmail.com> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <012701c80fe6$df9fddb0$5b238351@cr3lt> <4714ACAF.2040907@microsoft.com> Message-ID: <4714B23C.8070202@microsoft.com> Simon Marlow wrote: > Claus Reinke wrote: >>>> - if you provide a 'base' configuration that pulls in the stuff that >>>> used to be in base, the package will work >>> >>> I don't know of a way to do that. The name of the package is baked >>> into the object files at compile time, so you can't use the same >>> compiled module in more than one package. >> >> i've been wrong about this before, so check before you believe,-) but >> here is a hack i arrived at the last time we discussed this: >> >> [using time:Data.Time as a small example; ghc-6.6.1] >> >> 1. create, build, and install a package QTime, with default Setup.hs > ... >> 2. create, build, and install a package Time2, with default Setup.hs > ... >> 3. write and build a client module > > Ok, when I said above "I don't know a way to do that", I really meant > there's no way to do it by modifying the package database alone, which I > think is what Udo was after. > > Your scheme does work, and you have discovered how to make a package > that re-exports modules from other packages (I made a similar discovery > recently when looking into how to add support to Cabal for this). As > you can see, it's rather cumbersome, in that you need an extra dummy > package, and two stub modules for each module to be re-exported. Ah, I should add that due to technical limitations this scheme can't be used to make a base-2 that depends on base-3. Base is special in this respect, GHC only allows a single package called base to be linked into any given executable. The reason for this is that GHC can be independent of the version of the base package, and refer to it as just "base"; in theory it's possible to upgrade the base package independently of GHC. So we're restricted at the moment to providing only completely independent base-2 and base-3 in the same installation, and essentially that means having (at least) two copies of every package, one that depends on base-2 and one that depends on base-3. Perhaps we should revisit this decision, it would be better for GHC to depend explicitly on base-3, but allow a separate backwards-compatible base-2 that depends on base-3 to be installed alongside. OTOH, this will still lead to difficulties when you try to mix base-2 and base-3. Suppose that the Exception type changed, so that base-2 needs to provide its own version of Exception. The base-2:Exception will be incompatible with the base-3:Exception, and type errors will ensue if the two are mixed. If the base-3:Exception only added a constructor, then you could hide it in base-2 instead of defining a new type. However, if base-3 changed the type of a constructor, you're stuffed. Ah, I think we've discovered a use for the renaming feature that was removed in Haskell 1.3! Cheers, Simon From simonmarhaskell at gmail.com Tue Oct 16 08:57:01 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Oct 16 08:55:26 2007 Subject: Proposal: register a package as providing several API versions In-Reply-To: <4714AF6E.70903@list.mightyreason.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <4714AF6E.70903@list.mightyreason.com> Message-ID: <4714B51D.7060507@gmail.com> ChrisK wrote: > Simon Marlow wrote: >> Several good points have been raised in this thread, and while I might >> not agree with everything, I think we can all agree on the goal: things >> shouldn't break so often. > > I have another concrete proposal to avoid things breaking so often. Let us > steal from something that works: shared library versioning on unixy systems. > > On Max OS X, I note that I have, in /usr/lib: >> lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.2.dylib -> libcurl.3.dylib >> lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.3.0.0.dylib -> libcurl.3.dylib >> -rwxr-xr-x 1 root wheel 201156 Aug 17 17:14 libcurl.3.dylib >> lrwxr-xr-x 1 root wheel 15 Jul 24 2005 libcurl.dylib -> libcurl.3.dylib > > The above declaratively expresses that libcurl-3.3.0 provides the version 3 API > and the version 2 API. > > This is the capability that should be added to Haskell library packages. > > Right now a library can only declare a single version number. So if I update > hsFoo from 2.1.1 to 3.0.0 then I cannot express whether or not the version 3 API > is a superset of (backward compatible with) the version 2 API. Certainly, this is something we want to support. However, there's an important difference between shared-library linking and Haskell: in Haskell, a superset of an API is not backwards-compatible, because it has the potential to cause new name clashes. > Once it is possible to have cabal register the hsFoo-3.0.0 also as hsFoo-2 it > will be easy to upgrade to hsFoo. No old programs will fail to compile. > > Who here knows enough about the ghc-pkg database to say how easy or hard this > would be? It could be done using the tricks that Claus just posted and I followed up on. You'd need a separate package for hsFoo-2 that specifies exactly which bits of hsFoo-3 are re-exported. Given some Cabal support and a little extension in GHC, this could be made relatively painless for the library maintainer. Cheers, Simon From trac at galois.com Tue Oct 16 09:07:39 2007 From: trac at galois.com (Hackage) Date: Tue Oct 16 09:05:50 2007 Subject: [Hackage] #160: PatternSignatures missing in Extensions In-Reply-To: <042.dfdacb084ad3feeb7cafbb31f2921fac@localhost> References: <042.dfdacb084ad3feeb7cafbb31f2921fac@localhost> Message-ID: <051.0f9b7651b2d94538f8cab1b018842429@localhost> #160: PatternSignatures missing in Extensions ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: very easy (<1 hour) Ghcversion: 6.6 | Platform: Linux ---------------------+------------------------------------------------------ Comment (by guest): I'ld like to add that the error message for a wrong entry under extensions is quite poor: {{{ Parse of field 'extensions' failed: }}} Christian.Maeder@dfki.de -- Ticket URL: Hackage Hackage: Cabal and related projects From stefanor at cox.net Tue Oct 16 10:09:56 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Oct 16 10:08:18 2007 Subject: [Haskell-cafe] Re: Proposal: register a package as providing several API versions In-Reply-To: <4714B51D.7060507@gmail.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <4714AF6E.70903@list.mightyreason.com> <4714B51D.7060507@gmail.com> Message-ID: <20071016140956.GA3284@localhost.localdomain> On Tue, Oct 16, 2007 at 01:57:01PM +0100, Simon Marlow wrote: > Certainly, this is something we want to support. However, there's an > important difference between shared-library linking and Haskell: in > Haskell, a superset of an API is not backwards-compatible, because it has > the potential to cause new name clashes. This is the case on Unixy .so systems too, because the namespace is flat. If libreadline suddenly starts exporting a symbol named SDL_init, programs which use both readline and sdl will break. I have not seen this happen in practice. (Which might have something to do with the aforementioned name mangling :)) Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20071016/bbca6c34/attachment.bin From apfelmus at quantentunnel.de Tue Oct 16 09:48:19 2007 From: apfelmus at quantentunnel.de (apfelmus) Date: Tue Oct 16 11:05:12 2007 Subject: Proposal: register a package as providing several API versions In-Reply-To: <4714AF6E.70903@list.mightyreason.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <4714AF6E.70903@list.mightyreason.com> Message-ID: Simon Marlow wrote: > The proposed policy, for the sake of completeness is: x.y where: > > x changes ==> API changed > x constant but y changes ==> API extended only > x and y constant ==> API is identical > [..] > dependencies must specify a single x.y API version, or a range of > versions with an upper bound. What about x == 0? I mean, the intention of 0 is that 0.1, 0.2 and so on may well overthrow the API. But that's a bikeshed issue. ChrisK wrote: > The above declaratively expresses that libcurl-3.3.0 provides the version 3 API > and the version 2 API. Good idea. In the end, both proposals are based on the same observation: the dependency knows best which of its versions are compatible and which aren't. It's *not* a responsibility of the dependent package to know that. It only has to know one particular version it compiles against. So, it would just specify "I do compile with foobar 1.2" and let foobar 1.3 decide whether it's compatible with 1.2 or not. Given Simon's proposed policy, the answer would be "yes", if it were not for possible name clashes: > However, there's an important difference between shared-library > linking and Haskell: in Haskell, a superset of an API is not > backwards-compatible, because it has the potential to cause new name clashes. Solution? explicit imports? explicit module signatures with subtyping? implicit signature conversion foobar 1.3 -> foobar 1.2 on the package level? Regards, apfelmus From simonmarhaskell at gmail.com Tue Oct 16 11:52:17 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Oct 16 11:50:33 2007 Subject: [Haskell-cafe] Re: Proposal: register a package as providingseveral API versions In-Reply-To: <02c201c8100a$fcb951a0$5b238351@cr3lt> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com><4714A9D1.8070501@microsoft.com><4714AF6E.70903@list.mightyreason.com> <4714B51D.7060507@gmail.com> <02c201c8100a$fcb951a0$5b238351@cr3lt> Message-ID: <4714DE31.6050503@gmail.com> Claus Reinke wrote: >> It could be done using the tricks that Claus just posted and I >> followed up on. You'd need a separate package for hsFoo-2 that >> specifies exactly which bits of hsFoo-3 are re-exported. Given some >> Cabal support and a little extension in GHC, this could be made >> relatively painless for the library maintainer. > > are those tricks necessary in this specific case? couldn't we > have a list/range of versions in the version: field, and let cabal > handle the details? I don't understand what you're proposing here. Surely just writing version: 1.0, 2.0 isn't enough - you need to say what the 1.0 and 2.0 APIs actually *are*, and then wouldn't that require more syntax? I don't yet see a good reason to do this in a single .cabal file instead of two separate packages. The two-package way seems to require fewer extensions to Cabal. > aside: what happens if we try to combine two modules M and N > that use the same api A, but provided by two different packages > P1 and P2? say, M was built when P1 was still around, but when > N was built, P2 had replaced P1, still supporting A, but not necessarily > with the same internal representation as used in P1. Not sure what you mean by "try to combine". A concrete example? Cheers, Simon From ross at soi.city.ac.uk Tue Oct 16 14:36:49 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Oct 16 14:35:17 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <4714A9D1.8070501@microsoft.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> Message-ID: <20071016183649.GA5847@soi.city.ac.uk> On Tue, Oct 16, 2007 at 01:08:49PM +0100, Simon Marlow wrote: > So rather than keep replying to individual points, I'd like to make some > concrete proposals so we can make progress. > > 1. Document the version numbering policy. > > We should have done this earlier, but we didn't. The proposed policy, for > the sake of completeness is: x.y where: > > x changes ==> API changed > x constant but y changes ==> API extended only > x and y constant ==> API is identical > > further sub-versions may be added after the x.y, their meaning is > package-defined. This should be required for at least the GHC boot packages (and encouraged for others). I would make "API extended only" a bit more precise: any module that uses explicit import lists will not be affected by the changes. So one can add classes, types and functions, but not instances (except where either the class or the type is new). You probably can't add data constructors or fields, and have to be careful with new methods. I'd also prefer that major versions used two numbers, because that's common now, it supports the experimental versions 0.x apfelmus mentioned, and it makes it easier to leave room for development versions (possibly using an odd-even scheme). If you make your development repository available, and it contains API changes, you'll want its version number to have a larger major number. From isaacdupree at charter.net Tue Oct 16 15:25:35 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Oct 16 15:25:13 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071016183649.GA5847@soi.city.ac.uk> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016183649.GA5847@soi.city.ac.uk> Message-ID: <4715102F.7030704@charter.net> Ross Paterson wrote: > I would make "API extended only" a bit more precise: any module that uses > explicit import lists will not be affected by the changes. So one can > add classes, types and functions, but not instances (except where either > the class or the type is new). okay > You probably can't add data constructors > or fields, and have to be careful with new methods. If they're exported and new members of existing classes/datatypes, then you can't add them, because they might be imported with "class/typename(..)". (right?) What about semantic changes to the API? Including, adding a default to a class method changes the default from 'undefined', which someone might have relied on as the default (although it seems unlikely). Isaac From dons at galois.com Tue Oct 16 15:44:33 2007 From: dons at galois.com (Don Stewart) Date: Tue Oct 16 15:42:46 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <4714A9D1.8070501@microsoft.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> Message-ID: <20071016194433.GF15214@scytale.galois.com> simonmarhaskell: > Several good points have been raised in this thread, and while I might not > agree with everything, I think we can all agree on the goal: things > shouldn't break so often. > > So rather than keep replying to individual points, I'd like to make some > concrete proposals so we can make progress. > > 1. Document the version numbering policy. > > We should have done this earlier, but we didn't. The proposed policy, for > the sake of completeness is: x.y where: > > x changes ==> API changed > x constant but y changes ==> API extended only > x and y constant ==> API is identical > > further sub-versions may be added after the x.y, their meaning is > package-defined. Ordering on versions is lexicographic, given multiple > versions that satisfy a dependency Cabal will pick the latest. > > 2. Precise dependencies. > > As suggested by various people in this thread: we change the convention so > that dependencies must specify a single x.y API version, or a range of > versions with an upper bound. Cabal or Hackage can refuse to accept > packages that don't follow this convention (perhaps Hackage is a better > place to enforce it, and Cabal should just warn, I'm not sure). I agree. >= 1.0 isn't viable in the long term. Rather, a specific list, or bounded range of tested versions seems likely to be more robust. -- Don From ndmitchell at gmail.com Tue Oct 16 15:48:52 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Oct 16 15:47:15 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071016194433.GF15214@scytale.galois.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016194433.GF15214@scytale.galois.com> Message-ID: <404396ef0710161248r1fe1573t4e99872b3b21bae9@mail.gmail.com> Hi > I agree. >= 1.0 isn't viable in the long term. Rather, a specific list, > or bounded range of tested versions seems likely to be more robust. In general, if it compiles and type checks, it will work. It is rare that an interface stays sufficiently similar that the thing compiles, but then crashes at runtime. Given that, shouldn't the tested versions be something a machine figures out - rather than something each library author has to tend to with every new release of every other library in hackage? Thanks Neil From isaacdupree at charter.net Tue Oct 16 16:06:27 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Oct 16 16:05:51 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <404396ef0710161248r1fe1573t4e99872b3b21bae9@mail.gmail.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016194433.GF15214@scytale.galois.com> <404396ef0710161248r1fe1573t4e99872b3b21bae9@mail.gmail.com> Message-ID: <471519C3.1090503@charter.net> Neil Mitchell wrote: > Hi > >> I agree. >= 1.0 isn't viable in the long term. Rather, a specific list, >> or bounded range of tested versions seems likely to be more robust. > > In general, if it compiles and type checks, it will work. It is rare > that an interface stays sufficiently similar that the thing compiles, > but then crashes at runtime. True.. GoboLinux's package system records the exact set of versions something compiles with (just for reference), and uses min version bounds (and max bounds where needed) for dependencies. It's always possible for Haskell library implementation-bug-fixes to change relied-on behavior, as discussed in the original ECT description. I agree that compiling and type-checking is a pretty good sign of working. Passing tests (e.g. QuickCheck) could be tested too, where available. If optimizations and unsafePerformIO interact differently, different compiler versions could also affect whether something works correctly, but still compiles... But, the issue here is much more limited: we assume that there were some set of versions of these libraries that DID work, and, that every version of each library, on its own (or with only the libraries it depends on), works. So it might be valuable to record subjectively-working exact version sets, somewhere. Isaac From trac at galois.com Tue Oct 16 17:21:45 2007 From: trac at galois.com (Hackage) Date: Tue Oct 16 17:19:57 2007 Subject: [Hackage] #164: bad error message when using configuration flags that were not defined Message-ID: <043.2efa501ba956f2cb9a882d7bda76547a@localhost> #164: bad error message when using configuration flags that were not defined ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.0 Severity: minor | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ------------------------------+--------------------------------------------- Using a flag in an if condition when that flag has not been previously defined gives an unhelpful error message: {{{ -- flag foo never declared: if flag(foo) blah: else other: }}} We get the error message: {{{ cabal-setup: Environment not defined for all free vars }}} The error is reported by {{{Distribution.Configuration.simplifyCondTree}}} but the error should probably be checked for much earlier. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Tue Oct 16 18:15:14 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Oct 16 18:10:39 2007 Subject: suggestion for a small extension to configurations Message-ID: <1192572914.9844.208.camel@localhost> With the current issue of the split base library we have a lot of code like: flag split-base library if flag(split-base) build-depends: base >= 3.0, pretty, directory, etc else build-depends: base < 3.0 This does a backtracking search, checking both alternatives to see if one is satisfiable. It's a bit unsatisfactory however since we have to introduce a flag for a choice which really should be automatic and not visible to the user. It was always a deliberate part of the design of configurations that we should not let package authors make automatic decisions without the environment (packager or user) being able to influence the choice. So the question is, is there a special case that we can say really is an automatic decision that the user does not need to control with a flag? Here's my suggestion: library build-depends: base if package(base >= 3) build-depends: pretty, directory, etc and it is syntactic sugar for: flag _unnamed1 library build-depends: base if flag(_unnamed1) build-depends: base >= 3.0 build-depends: pretty, directory, etc else build-depends: !(base >= 3.0) So we introduce a new predicate 'package()' that tests the version number of a package that we've already declared that we depend on. It is crucial that it be one we already depend upon. It does not test packages in the environment generally, it tests the version of the package that the environment has or might impose. So we still introduce a backtracking point, it's just that now it's an backtracking without a named flag. This is ok because the decision about which branch to take is completely determined once the environment picks a version for the dependent package in question. Details... each package predicate test introduces it's own distinct anonymous flag. The flags are introduced in order, top to bottom, left to right and appear after all other named flags. eg: flag blah build-depends: foo, bar if package(foo > 1) && package (bar > 1) && flag(blah) ... else ... => flag blah flag _1 flag _2 build-depends: foo, bar if flag(_1) && flag(_2) && flag(blah) build-depends: foo > 1 build-depends: bar > 1 ... else build-depends: !(foo > 1) build-depends: !(bar > 1) ... Saying that we already depend on a package is interpreted relative to the position of the package() test in the overall condition tree. It means that to get to the branch where the package() test is, we must have that package in the build-depends explicitly in some parent node. Possibly as an extension we could allow it to appear in all the alternatives of some sibling node eg: So, overall, does that make sense? Is that sufficiently precise? Should we do it? Here's the canonical example. It's a package (tar) that works with ghc-6.4, 6.6 and 6.8 and uses bytestring: Flag bytestring-in-base Flag split-base library if flag(bytestring-in-base) -- bytestring was in base-2.0 and 2.1.1 build-depends: base >= 2.0 && < 2.2 else -- in base 1.0 and 3.0 bytestring is a separate package build-depends: base < 2.0 || >= 3, bytestring >= 0.9 if flag(split-base) build-depends: base >= 3.0, directory, old-time else build-depends: base < 3.0 which we could simplify to: library build-depends: base if package(base >= 3) directory, old-time if package(base < 2 || >= 3) build-depends: bytestring >= 0.9 Much nicer I think. Duncan From igloo at earth.li Tue Oct 16 18:30:03 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Oct 16 18:28:13 2007 Subject: CPP confusion In-Reply-To: <1192527986.9844.175.camel@localhost> References: <1192527986.9844.175.camel@localhost> Message-ID: <20071016223002.GA16485@matrix.chaos.earth.li> [can we keep this on just one mailing list please? cabal-devel@ makes most sense to me] On Tue, Oct 16, 2007 at 10:46:26AM +0100, Duncan Coutts wrote: > > The latest thing I've stumbled over is HsUnix.h in ghc-6.8. This header > file is for defines to use when pre-processing Haskell code. It used to > live in the global $GHCLIBDIR/include but now lives in the include dir > for the unix package. This is probably the right thing to do, however... > > How do packages that want to use this include actually use it? If they > #include it directly in a .hs file then it'll work since ghc -package > unix adds the unix package's include dir to the search path. But what if > someone needs to use it in a .hsc file? > > Well, then it does not work. It does not work because Cabal does not > pass these include directories to hsc2hs Is there a reason we can't just fix that, and pass hsc2hs "-Ifoo" for each includes directory "foo" in a package we depend on? > In fact this totally relies on a package > database to remember what search directories to use when pre-processing > dependent packages. In other words it only has a chance of working with > ghc at the moment, or nhc in future if/when it implements a package > database. Yes, I think that at some point all impls will need some sort of package database (or perhaps Cabal could manage a package database itself for some or all impls?). Thanks Ian From igloo at earth.li Tue Oct 16 18:45:13 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Oct 16 18:43:23 2007 Subject: suggestion for a small extension to configurations In-Reply-To: <1192572914.9844.208.camel@localhost> References: <1192572914.9844.208.camel@localhost> Message-ID: <20071016224513.GB16485@matrix.chaos.earth.li> On Tue, Oct 16, 2007 at 11:15:14PM +0100, Duncan Coutts wrote: > > each package predicate test introduces it's own distinct anonymous flag. > The flags are introduced in order, top to bottom, left to right and > appear after all other named flags. I don't have strong opinions either way (I'd say the extra complexity wasn't worthwhile personally, but you've had more experience with writing cabal configurations), but one thing that occurs to me: are people likely to write things like this?: if (base >= 3.0) build-depends: pretty if (base >= 3.0) build-depends: containers [...] If so then we'll want to spot that and only invent a single flag, or the exponential number of combinations might become significant. Thanks Ian From igloo at earth.li Tue Oct 16 19:35:43 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Oct 16 19:34:00 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <4714A9D1.8070501@microsoft.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> Message-ID: <20071016233543.GA17830@matrix.chaos.earth.li> [would it be possible to pick a single list to discuss this on please, so there is no danger of some people missing some subthreads if they aren't on all the lists, or getting messages 3 times if they are?] On Tue, Oct 16, 2007 at 01:08:49PM +0100, Simon Marlow wrote: > > 2. Precise dependencies. While not directly related to this, I have the impression some people want precise dependencies so that things work properly when multiple versions of a library are installed. Personally I'm not a fan of that, as if I have package foo: module Foo where data T package bar: module Bar where bar :: T package baz: module Baz where baz :: T -> () then baz bar might be a type error if I have multiple versions of foo installed and bar and baz have been compiled against different versions. Thanks Ian From duncan.coutts at worc.ox.ac.uk Tue Oct 16 20:28:45 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Oct 16 20:24:08 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071016233543.GA17830@matrix.chaos.earth.li> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016233543.GA17830@matrix.chaos.earth.li> Message-ID: <1192580925.9844.221.camel@localhost> On Wed, 2007-10-17 at 00:35 +0100, Ian Lynagh wrote: > [would it be possible to pick a single list to discuss this on please, > so there is no danger of some people missing some subthreads if they > aren't on all the lists, or getting messages 3 times if they are?] > > On Tue, Oct 16, 2007 at 01:08:49PM +0100, Simon Marlow wrote: > > > > 2. Precise dependencies. > > While not directly related to this, I have the impression some people > want precise dependencies so that things work properly when multiple > versions of a library are installed. > > Personally I'm not a fan of that, as if I have > > package foo: > module Foo where > data T > > package bar: > module Bar where > bar :: T > > package baz: > module Baz where > baz :: T -> () > > then > baz bar > might be a type error if I have multiple versions of foo installed and > bar and baz have been compiled against different versions. Sure, those are not compatible. But we can detect that just by looking at the dependencies of each package. The solution is to distinguish private and public dependencies and to slot packages on their own version numbers and all version numbers of the packages they publicly depend upon. Then in your example we'd just compile another copy of bar or baz using a compatible version of foo. This is what Nix does. Duncan From simonmarhaskell at gmail.com Wed Oct 17 05:26:16 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Oct 17 05:24:36 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <404396ef0710161248r1fe1573t4e99872b3b21bae9@mail.gmail.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016194433.GF15214@scytale.galois.com> <404396ef0710161248r1fe1573t4e99872b3b21bae9@mail.gmail.com> Message-ID: <4715D538.9060201@microsoft.com> Neil Mitchell wrote: > Hi > >> I agree. >= 1.0 isn't viable in the long term. Rather, a specific list, >> or bounded range of tested versions seems likely to be more robust. > > In general, if it compiles and type checks, it will work. It is rare > that an interface stays sufficiently similar that the thing compiles, > but then crashes at runtime. Given that, shouldn't the tested versions > be something a machine figures out - rather than something each > library author has to tend to with every new release of every other > library in hackage? The only reasonable way we have to test whether a package compiles with a new version of a dependency is to try compiling it. To do anything else would be duplicating what the compiler does, and risks getting it wrong. But you're right that tools could help a lot: for example, after a base version bump, Hackage could try to build all its packages against the new base to figure out which ones need source code modifications and which can probably just have their .cabal files tweaked to allow the new version. Hackage could tentatively fix the .cabal files itself and/or contact the maintainer. We'll really need some tool to analyse API changes too, otherwise API versioning is too error-prone. Anyone like to tackle this? It shouldn't be too hard using the GHC API.. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Wed Oct 17 07:15:08 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 07:13:16 2007 Subject: patch applied (cabal): Add logging functions notice, info, debug functions and use them consistently Message-ID: <20071017111507.GA30283@haskell.galois.com> Fri Oct 12 04:32:37 PDT 2007 Duncan Coutts * Add logging functions notice, info, debug functions and use them consistently We previously had this kind of code all over the place: > when (verbosity >= verbose) > (putStrLn "some message") We now replace that with: > info verbosity "some message" Much nicer. M ./Distribution/PackageDescription.hs -3 +2 M ./Distribution/Simple.hs -5 +4 M ./Distribution/Simple/Configure.hs -35 +29 M ./Distribution/Simple/GHC.hs -10 +7 M ./Distribution/Simple/Haddock.hs -11 +10 M ./Distribution/Simple/Hugs.hs -5 +4 M ./Distribution/Simple/Install.hs -8 +7 M ./Distribution/Simple/JHC.hs -5 +3 M ./Distribution/Simple/PreProcess.hs -2 +1 M ./Distribution/Simple/Program.hs -14 +11 M ./Distribution/Simple/Register.hs -3 +2 M ./Distribution/Simple/SrcDist.hs -6 +5 M ./Distribution/Simple/Utils.hs -12 +43 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 07:15:09 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 07:13:18 2007 Subject: patch applied (cabal): Update the TODO list, mostly removing things. Message-ID: <20071017111509.GA30306@haskell.galois.com> Fri Oct 12 05:17:02 PDT 2007 Duncan Coutts * Update the TODO list, mostly removing things. Most of these are duplicated by Trac bugs. We should try and get rid of this TODO file completely and just use Trac. M ./TODO -62 +11 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 07:15:10 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 07:13:20 2007 Subject: patch applied (cabal): Note current development version number in release notes Message-ID: <20071017111510.GA30322@haskell.galois.com> Fri Oct 12 05:18:35 PDT 2007 Duncan Coutts * Note current development version number in release notes M ./releaseNotes -1 +1 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 07:15:12 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 07:13:21 2007 Subject: patch applied (cabal): Move ghcVerbosity function into GHC module to share code Message-ID: <20071017111512.GA30338@haskell.galois.com> Sun Oct 14 09:57:30 PDT 2007 Duncan Coutts * Move ghcVerbosity function into GHC module to share code M ./Distribution/Simple/GHC.hs -4 +9 M ./Distribution/Simple/SetupWrapper.hs -7 +2 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 07:15:13 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 07:13:22 2007 Subject: patch applied (cabal): Translate flat files into sectionized files, by duplicating global Message-ID: <20071017111513.GA30354@haskell.galois.com> Tue Sep 25 07:49:21 PDT 2007 Thomas Schilling * Translate flat files into sectionized files, by duplicating global dependecies into each non-empty section. The previous solution dumped them into the library section, even if it would have been empty otherwise. M ./Distribution/PackageDescription.hs -30 +23 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 07:15:15 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 07:13:24 2007 Subject: patch applied (cabal): Improve error messages for failed sanity checks. Message-ID: <20071017111515.GA30371@haskell.galois.com> Tue Sep 25 07:49:55 PDT 2007 Thomas Schilling * Improve error messages for failed sanity checks. M ./Distribution/PackageDescription.hs -6 +10 From simonmarhaskell at gmail.com Wed Oct 17 07:54:12 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Oct 17 07:52:48 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071016183649.GA5847@soi.city.ac.uk> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016183649.GA5847@soi.city.ac.uk> Message-ID: <4715F7E4.1030002@gmail.com> I've written down the proposed policy for versioning here: http://haskell.org/haskellwiki/Package_versioning_policy It turned out there was a previous page written by Bulat that contained essentially this policy, but it wasn't linked from anywhere which explains why it was overlooked. I took the liberty of rewriting the text. I took into account Ross's suggestions that the major version should have two components, and that we need to be more precise about what it means to extend an API. After a round of editing, we can start to link to this page from everywhere, and start migrating packages to this scheme where necessary. Cheers, Simon From igloo at earth.li Wed Oct 17 09:39:49 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Oct 17 09:38:12 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <4715F7E4.1030002@gmail.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016183649.GA5847@soi.city.ac.uk> <4715F7E4.1030002@gmail.com> Message-ID: <20071017133949.GA28313@matrix.chaos.earth.li> On Wed, Oct 17, 2007 at 12:54:12PM +0100, Simon Marlow wrote: > I've written down the proposed policy for versioning here: > > http://haskell.org/haskellwiki/Package_versioning_policy This says: If [...] instances were added or removed, then the new A.B must be greater than the previous A.B. This presumably includes changing module imports, or depending on a newer version of a package, which results in the visible instances changing? I think this should be spelt out in the policy. The example: build-depends: mypkg == 2.1.1 should be: build-depends: mypkg >= 2.1.1, mypkg < 2.1.2 with the current dependency syntax/semantics. Thanks Ian From ross at soi.city.ac.uk Wed Oct 17 09:44:19 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Oct 17 09:42:42 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <4715F7E4.1030002@gmail.com> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016183649.GA5847@soi.city.ac.uk> <4715F7E4.1030002@gmail.com> Message-ID: <20071017134419.GA3146@soi.city.ac.uk> On Wed, Oct 17, 2007 at 12:54:12PM +0100, Simon Marlow wrote: > I've written down the proposed policy for versioning here: > > http://haskell.org/haskellwiki/Package_versioning_policy > > It turned out there was a previous page written by Bulat that contained > essentially this policy, but it wasn't linked from anywhere which explains > why it was overlooked. I took the liberty of rewriting the text. You wrote: > A client that wants to specify that they depend on a particular version > of the API can specify a particular A.B.C and be sure of getting that > API only. For example, build-depends: mypkg-2.1.1 Are you proposing an extension along the lines of that proposed by Thomas (and Bulat, and others), i.e. this would be equivalent to build-depends: mypkg >= 2.1.1 && < 2.1.2 ? The current syntax of mypkg == 2.1.1 would match the initial release but not subsequent patch releases. From duncan.coutts at worc.ox.ac.uk Wed Oct 17 14:30:52 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 14:29:02 2007 Subject: patch applied (cabal): Change the handling of cpp & ghc flags for hsc2hs Message-ID: <20071017183052.GA4707@haskell.galois.com> Tue Oct 16 16:16:52 PDT 2007 Duncan Coutts * Change the handling of cpp & ghc flags for hsc2hs The hsc2hs that comes with ghc uses ghc as the C compiler. This means we must escape the real cc flags. It also means we can ask ghc to add extra include dirs that we might need to find includes of dependent packages. This is a bit of a hack. In the longer term it'd be better for Cabal to collect the include dirs and cc options of dependent packages and to pass them explicitly itself. M ./Distribution/Simple/PreProcess.hs -20 +35 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 14:30:54 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 14:29:04 2007 Subject: patch applied (cabal): Figure out if hsc2hs is using gcc or ghc as it's C compiler Message-ID: <20071017183053.GA4733@haskell.galois.com> Wed Oct 17 07:31:08 PDT 2007 Duncan Coutts * Figure out if hsc2hs is using gcc or ghc as it's C compiler and pass the appropriate flags on the basis of knowing that. This is a hack. What we should do longer term is make hsc2hs always use gcc as it's C compiler and have Cabal figure out the right flags to pass it, rather than using ghc to pass on the appropriate flags to gcc. M ./Distribution/Simple/PreProcess.hs -3 +4 M ./Distribution/Simple/Program.hs -8 +31 M ./Distribution/Simple/Utils.hs -4 +11 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 14:30:55 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 14:29:04 2007 Subject: patch applied (cabal): Add a "cpp-options:" field and use it for pre-processing .hs .hsc .chs files Message-ID: <20071017183055.GA4749@haskell.galois.com> Wed Oct 17 09:47:47 PDT 2007 Duncan Coutts * Add a "cpp-options:" field and use it for pre-processing .hs .hsc .chs files This is for pre-processing Haskell modules, not for C code. We already have cc-options for that purpose. Up 'til now people have been abusing ghc-options for this purpose. Even Cabal itself was guilty of doing that. M ./Distribution/PackageDescription.hs +6 M ./Distribution/Simple/GHC.hs +1 M ./Distribution/Simple/PreProcess.hs -9 +6 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 14:30:57 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 14:29:07 2007 Subject: patch applied (cabal): Use cpp-options rather than abusing ghc-options Message-ID: <20071017183057.GA4769@haskell.galois.com> Wed Oct 17 09:49:14 PDT 2007 Duncan Coutts * Use cpp-options rather than abusing ghc-options M ./Cabal.cabal -4 +2 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 14:31:01 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 14:29:09 2007 Subject: patch applied (cabal-branches/cabal-1.2): Change the handling of cpp & ghc flags for hsc2hs Message-ID: <20071017183101.GA4795@haskell.galois.com> Tue Oct 16 16:16:52 PDT 2007 Duncan Coutts * Change the handling of cpp & ghc flags for hsc2hs The hsc2hs that comes with ghc uses ghc as the C compiler. This means we must escape the real cc flags. It also means we can ask ghc to add extra include dirs that we might need to find includes of dependent packages. This is a bit of a hack. In the longer term it'd be better for Cabal to collect the include dirs and cc options of dependent packages and to pass them explicitly itself. M ./Distribution/Simple/PreProcess.hs -20 +35 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 14:31:03 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 14:29:12 2007 Subject: patch applied (cabal-branches/cabal-1.2): When parsing ghc-pkg output, only look at the first package.conf file for GlobalPackageDB and SpecificPackageDB, and all package.conf files for UserPackageDB. Message-ID: <20071017183103.GA4811@haskell.galois.com> Tue Oct 16 02:52:54 PDT 2007 bjorn@bringert.net * When parsing ghc-pkg output, only look at the first package.conf file for GlobalPackageDB and SpecificPackageDB, and all package.conf files for UserPackageDB. Before, we would consider user packages when fulfilling dependencies for global installs. ghc-pkg will refuse to install packages globally if they use user packages. Thus, without this patch, global installs can fail when you have user packages installed. M ./Distribution/Simple/GHC.hs -2 +10 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 14:31:04 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 14:29:14 2007 Subject: patch applied (cabal-branches/cabal-1.2): Figure out if hsc2hs is using gcc or ghc as it's C compiler Message-ID: <20071017183104.GA4827@haskell.galois.com> Wed Oct 17 07:31:08 PDT 2007 Duncan Coutts * Figure out if hsc2hs is using gcc or ghc as it's C compiler and pass the appropriate flags on the basis of knowing that. This is a hack. What we should do longer term is make hsc2hs always use gcc as it's C compiler and have Cabal figure out the right flags to pass it, rather than using ghc to pass on the appropriate flags to gcc. M ./Distribution/Simple/PreProcess.hs -3 +4 M ./Distribution/Simple/Program.hs -8 +31 M ./Distribution/Simple/Utils.hs -4 +11 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 14:31:06 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 14:29:15 2007 Subject: patch applied (cabal-branches/cabal-1.2): Add a "cpp-options:" field and use it for pre-processing .hs .hsc .chs files Message-ID: <20071017183106.GA4843@haskell.galois.com> Wed Oct 17 09:47:47 PDT 2007 Duncan Coutts * Add a "cpp-options:" field and use it for pre-processing .hs .hsc .chs files This is for pre-processing Haskell modules, not for C code. We already have cc-options for that purpose. Up 'til now people have been abusing ghc-options for this purpose. Even Cabal itself was guilty of doing that. M ./Distribution/PackageDescription.hs +6 M ./Distribution/Simple/GHC.hs +1 M ./Distribution/Simple/PreProcess.hs -9 +6 From duncan.coutts at worc.ox.ac.uk Wed Oct 17 14:31:07 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Oct 17 14:29:16 2007 Subject: patch applied (cabal-branches/cabal-1.2): Use cpp-options rather than abusing ghc-options Message-ID: <20071017183107.GA4859@haskell.galois.com> Wed Oct 17 09:50:43 PDT 2007 Duncan Coutts * Use cpp-options rather than abusing ghc-options Cabal-1.2 branch version of an equivalent patch in Cabal HEAD M ./Cabal.cabal -4 +2 From igloo at earth.li Wed Oct 17 15:28:07 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Oct 17 15:26:20 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <1192580925.9844.221.camel@localhost> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016233543.GA17830@matrix.chaos.earth.li> <1192580925.9844.221.camel@localhost> Message-ID: <20071017192807.GA530@matrix.chaos.earth.li> On Wed, Oct 17, 2007 at 01:28:45AM +0100, Duncan Coutts wrote: > On Wed, 2007-10-17 at 00:35 +0100, Ian Lynagh wrote: > > > > package foo: > > module Foo where > > data T > > > > package bar: > > module Bar where > > bar :: T > > > > package baz: > > module Baz where > > baz :: T -> () > > > > then > > baz bar > > might be a type error if I have multiple versions of foo installed and > > bar and baz have been compiled against different versions. > > Sure, those are not compatible. But we can detect that just by looking > at the dependencies of each package. In general it is possible to have 2 different versions of a package in a single program, though, e.g. bar and baz could internally use different versions of a binary-tree package. Thanks Ian From simonmarhaskell at gmail.com Thu Oct 18 04:59:14 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Oct 18 04:57:38 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071017134419.GA3146@soi.city.ac.uk> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016183649.GA5847@soi.city.ac.uk> <4715F7E4.1030002@gmail.com> <20071017134419.GA3146@soi.city.ac.uk> Message-ID: <47172062.9040300@microsoft.com> Ross Paterson wrote: > On Wed, Oct 17, 2007 at 12:54:12PM +0100, Simon Marlow wrote: >> I've written down the proposed policy for versioning here: >> >> http://haskell.org/haskellwiki/Package_versioning_policy >> >> It turned out there was a previous page written by Bulat that contained >> essentially this policy, but it wasn't linked from anywhere which explains >> why it was overlooked. I took the liberty of rewriting the text. > > You wrote: > >> A client that wants to specify that they depend on a particular version >> of the API can specify a particular A.B.C and be sure of getting that >> API only. For example, build-depends: mypkg-2.1.1 > > Are you proposing an extension along the lines of that proposed by > Thomas (and Bulat, and others), i.e. this would be equivalent to > build-depends: mypkg >= 2.1.1 && < 2.1.2 ? Yes, I should have mentioned that, thanks. I'll update the page shortly with this suggestion and others. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Thu Oct 18 05:48:10 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 18 05:46:17 2007 Subject: patch applied (cabal-branches/cabal-1.2): Bump minor version number to 1.2.1 Message-ID: <20071018094809.GA22227@haskell.galois.com> Wed Oct 17 11:29:39 PDT 2007 Duncan Coutts * Bump minor version number to 1.2.1 We've added a couple minor features since 1.2.0 M ./Cabal.cabal -2 +2 M ./Makefile -2 +2 M ./releaseNotes -1 +1 From trac at galois.com Thu Oct 18 07:41:26 2007 From: trac at galois.com (Hackage) Date: Thu Oct 18 07:39:42 2007 Subject: [Hackage] #98: cabal assumes -x option for linking In-Reply-To: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> References: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> Message-ID: <070.773c37991043761290dd02bbc38e5961@localhost> #98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder@dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Changes (by guest): * cc: Christian.Maeder@dfki.de (added) * reporter: maeder@tzi.de => Christian.Maeder@dfki.de * version: 1.1.6 => 1.2.0 * milestone: Cabal-1.4 => Cabal-1.2 Comment: This ticket needs a desperate fix for the ghc-6.8.1 release! Furthermore the generated file libraries/base/GNUMakefile contained "`xargs -s 30000`" which is too big for Solaris (the maximal value is 2048) -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Thu Oct 18 09:10:11 2007 From: trac at galois.com (Hackage) Date: Thu Oct 18 09:08:26 2007 Subject: [Hackage] #98: cabal assumes -x option for linking In-Reply-To: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> References: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> Message-ID: <070.19e84da0303055b1a9a5d4485ede1f27@localhost> #98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder@dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by guest): this is how the error message looks like: {{{ /usr/ccs/bin/ld: illegal option -- x usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s) [-64] enforce a 64-bit link-edit [-a] create an absolute file [-b] do not do special PIC relocations in a.out [-B direct | nodirect] establish direct bindings, or inhibit direct binding to, the object being created [-B dynamic | static] search for shared libraries|archives [-B eliminate] eliminate unqualified global symbols from the symbol table [-B group] relocate object from within group [-B local] reduce unqualified global symbols to local [-B reduce] process symbol reductions [-B symbolic] bind external references to definitions when creating shared objects [-c name] record configuration file `name' [-C] demangle C++ symbol name diagnostics [-d y | n] operate in dynamic|static mode [-D token,...] print diagnostic messages [-e epsym] use `epsym' as entry point address [-f name] specify library for which this file is an auxiliary filter [-F name] specify library for which this file is a filter [-G] create a shared object [-h name] use `name' as internal shared object identifier [-i] ignore LD_LIBRARY_PATH setting [-I name] use `name' as path of interpreter [-l x] search for libx.so or libx.a [-L path] search for libraries in directory `path' [-m] print memory map [-M mapfile] use processing directives contained in `mapfile' [-N string] create a dynamic dependency for `string' [-o outfile] name the output file `outfile' [-p auditlib] identify audit library to accompany this object [-P auditlib] identify audit library for processing the dependencies of this object [-Q y | n] do|do not place version information in output file [-r] create a relocatable object [-R path] specify a library search path to be used at run time [-s] strip any symbol and debugging information [-S supportlib] specify a link-edit support library [-t] do not warn of multiply-defined symbols that have different sizes or alignments [-u symname] create an undefined symbol `symname' [-V] print version information [-Y P,dirlist] use `dirlist' as a default path when searching for libraries [-z absexec] when building an executable absolute symbols referenced in dynamic objects are promoted to the executable [-z allextract | defaultextract | weakextract] extract all member files, only members that resolve undefined tor tentative symbols, or allow extraction of archive members to resolvetweak references from archive files [-z altexec64] execute the 64-bit link-editor [-z combreloc] combine multiple relocation sections [-z defs] disallow undefined symbol references [-z direct | nodirect] enable|disable direct binding to shared object dependencies [-z endfiltee] marks a filtee such that it will terminate a filters search [-z finiarray=function] name of function to be appended to the .finiarray [-z groupperm | nogroupperm] enable|disable setting of group permissions on dynamic dependencies [-z help ] print this usage message [-z ignore | record] ignore|record unused dynamic dependencies [-z initarray=function] name of function to be appended to the .initarray [-z initfirst] mark object to indicate that its .init section should be executed before the .init section of any other objects [-z interpose] dynamic object is to be an `interposer' on direct bindings [-z lazyload | nolazyload] enable|disable delayed loading of shared object dependencies [-z ld32=arg1,arg2,...] define arguments applicable to the 32-bit class of ld(1) [-z ld64=arg1,arg2,...] define arguments applicable to the 64-bit class of ld(1) [-z loadfltr] mark filter as requiring immediate loading of its filtees at runtime [-z muldefs] allow multiply-defined symbols [-z nocompstrtab] disable compression of string tables [-z nodefs] allow undefined symbol references [-z nodefaultlib] mark object to ignore any default library search path [-z nodelete] mark object as non-deletable [-z nodlopen] mark object as non-dlopen()'able [-z nodump] mark object as non-dldump()'able [-z now] mark object as requiring non-lazy binding [-z nopartial] expand any partially initialized symbols [-z noversion] don't record any version sections [-z origin] mark object as requiring $ORIGIN processing [-z preinitarray=function] name of function to be appended to the .preinitarray [-z redlocsym] reduce local syms in .symtab to a minimum [-z rescan] rescan archive list until no further member extraction occurs [-z text] disallow output relocations against text [-z textoff] allow output relocations against text [-z textwarn] warn if there are relocations against text [-z verbose] generate warnings for suspicious processings gmake[2]: *** [dist/build/HSbase-3.0.o] Error 1 }}} I could continue with a gnu linker only after cleaning up completely. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Thu Oct 18 09:57:19 2007 From: trac at galois.com (Hackage) Date: Thu Oct 18 09:55:33 2007 Subject: [Hackage] #98: cabal assumes -x option for linking In-Reply-To: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> References: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> Message-ID: <070.f684e2f78c29459faa2ef349235cd753@localhost> #98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder@dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by guest): No, I could not continue! When I put a gnu linker first in my path then ghc-inplace passes the -x option to the linker, which is wrong, because gcc is used as a linker which in turn is based on the Solaris linker. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Thu Oct 18 11:21:27 2007 From: trac at galois.com (Hackage) Date: Thu Oct 18 11:19:41 2007 Subject: [Hackage] #98: cabal assumes -x option for linking In-Reply-To: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> References: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> Message-ID: <070.fb20e7537b7685d051fa5116b399acb6@localhost> #98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder@dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by nominolo): The documentation for {{{ld}}} on Ubuntu reads: {{{ -x --discard-all Delete all local symbols. }}} That seems to be corresponding to {{{ [-z redlocsym] reduce local syms in .symtab to a minimum }}}. Maybe it could even be omitted. There actually is a FIXMe in Distrubution/Simple/GHC.hs line 348. Could you try removing that line, rebuild Cabal and try again? -- Ticket URL: Hackage Hackage: Cabal and related projects From ross at soi.city.ac.uk Thu Oct 18 12:46:54 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Oct 18 12:44:58 2007 Subject: patch applied (cabal): don't fail if xxx_hsc_make.c is gone Message-ID: <20071018164654.GA32340@haskell.galois.com> Thu Oct 18 09:42:45 PDT 2007 Ross Paterson * don't fail if xxx_hsc_make.c is gone The non-GHC hsc2hs deletes it even if the compilation fails. M ./Distribution/Simple/Program.hs -1 +2 From trac at galois.com Thu Oct 18 15:28:41 2007 From: trac at galois.com (Hackage) Date: Thu Oct 18 15:26:55 2007 Subject: [Hackage] #98: cabal assumes -x option for linking In-Reply-To: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> References: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> Message-ID: <070.3450ce8c6189e18cd5c40daa3d510914@localhost> #98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder@dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by guest): Omitting this line works under Solaris. Maybe this explains why my binaries are about 20% bigger. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Thu Oct 18 15:51:00 2007 From: trac at galois.com (Hackage) Date: Thu Oct 18 15:49:16 2007 Subject: [Hackage] #98: cabal assumes -x option for linking In-Reply-To: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> References: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> Message-ID: <070.2cec3e10c7d571cec0175210eae43ee8@localhost> #98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder@dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by guest): No, it did no work yet. It seems I have to edit `libraries/Cabal/Distribution/Simple/GHC/Makefile.in`, too! -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Thu Oct 18 15:57:19 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 18 15:55:24 2007 Subject: patch applied (cabal-branches/cabal-1.2): Update changelog for 1.2.1 Message-ID: <20071018195719.GA4472@haskell.galois.com> Thu Oct 18 12:15:19 PDT 2007 Duncan Coutts * Update changelog for 1.2.1 M ./changelog +13 From duncan.coutts at worc.ox.ac.uk Thu Oct 18 15:57:21 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 18 15:55:26 2007 Subject: patch applied (cabal-branches/cabal-1.2): Correct the spelling of mingw32 in os alias list Message-ID: <20071018195721.GA4494@haskell.galois.com> Thu Oct 18 12:56:41 PDT 2007 Duncan Coutts * Correct the spelling of mingw32 in os alias list Doh! M ./Distribution/Configuration.hs -1 +1 From duncan.coutts at worc.ox.ac.uk Thu Oct 18 18:24:23 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 18 18:22:32 2007 Subject: patch applied (cabal-branches/cabal-1.2): don't fail if xxx_hsc_make.c is gone Message-ID: <20071018222423.GA7987@haskell.galois.com> Thu Oct 18 09:42:45 PDT 2007 Ross Paterson * don't fail if xxx_hsc_make.c is gone The non-GHC hsc2hs deletes it even if the compilation fails. M ./Distribution/Simple/Program.hs -1 +2 From duncan.coutts at worc.ox.ac.uk Thu Oct 18 18:53:46 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Oct 18 18:49:00 2007 Subject: [Haskell] Re: Trying to install binary-0.4 In-Reply-To: <20071017192807.GA530@matrix.chaos.earth.li> References: <20071014140922.GA25871@matrix.chaos.earth.li> <20071015203802.GA3229@web.de> <47147355.6020109@gmail.com> <200710162354.37812.dm.maillists@gmail.com> <4714A9D1.8070501@microsoft.com> <20071016233543.GA17830@matrix.chaos.earth.li> <1192580925.9844.221.camel@localhost> <20071017192807.GA530@matrix.chaos.earth.li> Message-ID: <1192748026.8926.35.camel@localhost> On Wed, 2007-10-17 at 20:28 +0100, Ian Lynagh wrote: > On Wed, Oct 17, 2007 at 01:28:45AM +0100, Duncan Coutts wrote: > > On Wed, 2007-10-17 at 00:35 +0100, Ian Lynagh wrote: > > > might be a type error if I have multiple versions of foo installed and > > > bar and baz have been compiled against different versions. > > > > Sure, those are not compatible. But we can detect that just by looking > > at the dependencies of each package. > > In general it is possible to have 2 different versions of a package in a > single program, though, e.g. bar and baz could internally use different > versions of a binary-tree package. Right, but only if those packages are used privately, ie such that types from the dependent packages do not leak into their public api, since that would allow the type error you originally pointed out. If we distinguish private use of a dependent package then we know it does not matter if we end up using two versions of it in a single program. Duncan From trac at galois.com Thu Oct 18 20:12:26 2007 From: trac at galois.com (Hackage) Date: Thu Oct 18 20:10:44 2007 Subject: [Hackage] #98: cabal assumes -x option for linking In-Reply-To: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> References: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> Message-ID: <070.5ef9da7f1becafa11f365989bbca3a88@localhost> #98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder@dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by duncan): See also http://hackage.haskell.org/trac/ghc/ticket/1786#comment:2 where I describe one route to a fix. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Fri Oct 19 07:21:13 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Oct 19 07:16:25 2007 Subject: -O in 6.8.1-candidate In-Reply-To: References: <20071017184913.GA25033@scico.botik.ru> <20071017185123.GD8916@scytale.galois.com> <1192657696.8926.22.camel@localhost> <20071018070249.GA1706@scico.botik.ru> <1192753527.9251.1.camel@localhost> <20071019073404.GA23088@scico.botik.ru> <1192785244.9251.19.camel@localhost> Message-ID: <1192792873.9251.27.camel@localhost> On Fri, 2007-10-19 at 10:42 +0100, Simon Peyton-Jones wrote: > | In general the users should never have to modify the .cabal file. For > | the common settings that we expect the user to want to control Cabal > | provides configure flags. > | > > .... > > | The idea is that instead of having to find the options for each > | implementation you might want to use, that Cabal knows the right > options > | for each compiler to use a feature like optimisation or profiling or > | whatever. > > You have a clear mental model of how Cabal is intended to be used -- > although it also provides trapdoors (like ghc-options) for when the > intended path isn't adequate. But that mental model is much clearer > to you and the other Cabal developers than it is to Cabal users like > Serge and me. > > Would it be worth writing a new section in the Cabal manual that > describes the "intended use model" for Cabal, for the benefit of Cabal > users? That way you'd be able to explain this stuff once and for all. > > Documentation often focuses on the knobs ("turn the steering wheel to > make the car change direction"), and omit the larger mental model of > what is going on ("cars should be driven on a road"). Yes. Here's a new introduction for the user's guide. Comments and improvements welcome. Duncan Introduction Developers write Cabal packages. These can be for libraries or executables. This involves writing the code obviously and also creating a .cabal file. The .cabal file contains some information about the package. Some of this information is needed to actually build the package and some is just useful for identifying the package when it comes to distribution. name: Foo version: 1.0 library build-depends: base exposed-modules: Foo Users install Cabal packages so they can use them. It is not expected that users will have to modify any of the information in the .cabal file. Cabal does provide a number of ways for a user to customise how and where a package is installed. They can decide where a package will be installed, which Haskell implementation to use and whether to build optimised code or build with the ability to profile code. tar -xzf Foo-1.0.tar.gz cd Foo-1.0 cabal-setup configure --with-compiler=ghc-6.4.2 --prefix=$HOME --user cabal-setup build cabal-setup install One of the purposes of Cabal is to make it easier to build a package with different Haskell implementations. So it provides abstractions of features present in different Haskell implementations and wherever possible it is best to take advantage of these to increase portability. Where necessary however it is possible to use specific features of specific implementations. For example one of the pieces of information a package author can put in the package's .cabal file is what language extensions the code uses. This is far preferable to specifying flags for a specific compiler as it allows Cabal to pick the right flags for the Haskell implementation that the user picks. It also allows Cabal to figure out if the language extension is even supported by the Haskell implementation that the user picks. Where compiler-specific options are needed however, there is an "escape hatch" available. The developer can specify implementation-specific options and more generally there is a configuration mechanism to customise many aspects of how a package is built depending on the Haskell implementation, the Operating system, computer architecture and user-specified configuration flags. name: Foo version: 1.0 library build-depends: base exposed-modules: Foo extensions: ForeignFunctionInterface ghc-options: -Wall nhc98-options: -K4m if os(windows) build-depends: Win32 From trac at galois.com Fri Oct 19 10:39:04 2007 From: trac at galois.com (Hackage) Date: Fri Oct 19 10:37:15 2007 Subject: [Hackage] #98: cabal assumes -x option for linking In-Reply-To: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> References: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> Message-ID: <070.63c39dc7032329b3c32a0273134b3d8a@localhost> #98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder@dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by guest): Maybe LDFLAGS should be appropriately set by configure and used in the sources instead of -x. Meanwhile the ghc-6.8.0.20071017 sources (without extra-libs) went through. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Fri Oct 19 13:54:31 2007 From: trac at galois.com (Hackage) Date: Fri Oct 19 13:52:43 2007 Subject: [Hackage] #98: cabal assumes -x option for linking In-Reply-To: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> References: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> Message-ID: <070.72bfe2c02d37d9c78face479f4a2d3a5@localhost> #98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder@dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by duncan): You misunderstand. The Makefile is generated by Cabal. So it's nothing to do with GHC's configure script and everything to do with Cabal deciding what the appropriate flags are. As it happens because of the Makefile stuff we'll have to fix it in two places in Cabal, once for the ordinary Cabal build stuff and once for where Cabal generates the Makefile. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Fri Oct 19 14:11:02 2007 From: trac at galois.com (Hackage) Date: Fri Oct 19 14:09:16 2007 Subject: [Hackage] #98: cabal assumes -x option for linking In-Reply-To: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> References: <061.b59dc7864b008d7b0f368657b6b769bb@localhost> Message-ID: <070.e0aaf4ff4bcd096cf33f055aac34993a@localhost> #98: cabal assumes -x option for linking ---------------------------------------+------------------------------------ Reporter: Christian.Maeder@dfki.de | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Cabal-1.2 Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Other Unix ---------------------------------------+------------------------------------ Comment (by guest): I quite understood that a Makefile.hs is generated from Makefile.in and that Cabal generates a GNUMakefile. I suggest that "Setup configure" should find out a proper value for a (new or further) LDFLAGS variable that is then used in conjunction with LD (instead of -x). -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Sun Oct 21 09:28:34 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Oct 21 09:26:32 2007 Subject: patch applied (cabal): Correct the spelling of mingw32 in os alias list Message-ID: <20071021132833.GA1805@haskell.galois.com> Thu Oct 18 12:56:41 PDT 2007 Duncan Coutts * Correct the spelling of mingw32 in os alias list Doh! M ./Distribution/Configuration.hs -1 +1 From duncan.coutts at worc.ox.ac.uk Sun Oct 21 09:31:33 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Oct 21 09:29:28 2007 Subject: patch applied (cabal-branches/cabal-1.2): TAG 1.2.1 Message-ID: <20071021133133.GA1914@haskell.galois.com> Sun Oct 21 05:08:40 PDT 2007 Duncan Coutts tagged 1.2.1 From davve at dtek.chalmers.se Sun Oct 21 19:25:31 2007 From: davve at dtek.chalmers.se (David Waern) Date: Sun Oct 21 19:23:26 2007 Subject: Patch for Haddock 2.0 support Message-ID: <64605.193.11.241.252.1193009131.squirrel@webmail.chalmers.se> Hi, here's the (new) patch that adds support for Haddock 2.0. David -------------- next part -------------- A non-text attachment was scrubbed... Name: haddock-cabal.patch Type: text/x-patch Size: 13618 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20071022/1bbc30a4/haddock-cabal.bin From ross at soi.city.ac.uk Mon Oct 22 05:13:44 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Oct 22 05:11:37 2007 Subject: patch applied (cabal): typo in comment Message-ID: <20071022091344.GA21322@haskell.galois.com> Mon Oct 22 02:12:35 PDT 2007 Ross Paterson * typo in comment M ./Cabal.cabal -1 +1 From trac at galois.com Mon Oct 22 16:05:39 2007 From: trac at galois.com (Hackage) Date: Mon Oct 22 16:03:30 2007 Subject: [Hackage] #165: The ./configure configure hook should complain if ./configure does not exist Message-ID: <042.8d24449a254143a160d4a5f3273a153b@localhost> #165: The ./configure configure hook should complain if ./configure does not exist ---------------------+------------------------------------------------------ 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 | ---------------------+------------------------------------------------------ We often have problems with people not running auto(re)conf before Setup configure, and things breaking later on. The hook that runs ./configure should fail if ./configure doesn't exist; it probably shouldn't give any suggestion on how to create it, as people will blindly follow the suggestion and one size probably won't fit all. This essentially depends on the proposals to split up hooks into smaller, composable parts. Ian Lynagh -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Mon Oct 22 19:12:13 2007 From: trac at galois.com (Hackage) Date: Mon Oct 22 19:10:04 2007 Subject: [Hackage] #165: The ./configure configure hook should complain if ./configure does not exist In-Reply-To: <042.8d24449a254143a160d4a5f3273a153b@localhost> References: <042.8d24449a254143a160d4a5f3273a153b@localhost> Message-ID: <051.962e1c96b0239bb5dd45356acc2fd782@localhost> #165: The ./configure configure hook should complain if ./configure does not exist ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------+------------------------------------------------------ Comment (by duncan): Certainly {{{build-type: Configure}}} should complain if ./configure cannot be found/run. Similarly, {{{defaultMainWithHooks autoconfHooks}}} should fail if {{{./configure}}} is not found, however {{{defaultMainWithHooks defaultHooks}}} is a mess because it's not actually the default but some packages use that thinking it is the default. Or if they extend defaultHooks but do not especially want to run {{{./configure}}}. So it works for them at the moment but would fail if we made that a hard error. -- Ticket URL: Hackage Hackage: Cabal and related projects From simonmarhaskell at gmail.com Tue Oct 23 05:34:40 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue Oct 23 05:32:36 2007 Subject: darcs patch: Refuse to run any commands if the .cabal has been modified Message-ID: <471DC030.30304@gmail.com> I think we want to get this patch into the Cabal shipped with GHC 6.8.1. It closes one possible way that spurious build failures can occur when tracking development with multiple packages. The xmonad team report that this is a common problem for users. patch description: Tue Oct 23 10:31:11 BST 2007 Simon Marlow * Refuse to run any commands if the .cabal has been modified See GHC bug #1372 This is a consistency check, intended to prevent this class of build failures: * Package P is updated, its version number is bumped, the new version is compiled and installed. * Package Q depends on P. Q is modified to use the new P, and Q's .cabal file is updated with changes to the build-depends field to depend on the new version of P. * The user has an old build of Q. They pull the changes to Q and 'setup build' without cleaning or re-configuring. Build errors ensue, because the code of Q depends on changes to P's API, and we're still building against the old P. Note that you can't get segfaults this way, only build errors. This also relies on some new consistency checking in GHC 6.8 to work properly. If the user re-configures their Q build and then issues 'setup build' without cleaning, GHC must now realise that the package flags have changed, and re-compile all the affected Q modules. GHC 6.6 would not do this, but 6.8 does. -------------- next part -------------- New patches: [Refuse to run any commands if the .cabal has been modified Simon Marlow **20071023093111 See GHC bug #1372 This is a consistency check, intended to prevent this class of build failures: * Package P is updated, its version number is bumped, the new version is compiled and installed. * Package Q depends on P. Q is modified to use the new P, and Q's .cabal file is updated with changes to the build-depends field to depend on the new version of P. * The user has an old build of Q. They pull the changes to Q and 'setup build' without cleaning or re-configuring. Build errors ensue, because the code of Q depends on changes to P's API, and we're still building against the old P. Note that you can't get segfaults this way, only build errors. This also relies on some new consistency checking in GHC 6.8 to work properly. If the user re-configures their Q build and then issues 'setup build' without cleaning, GHC must now realise that the package flags have changed, and re-compile all the affected Q modules. GHC 6.6 would not do this, but 6.8 does. ] { hunk ./Distribution/Simple/Configure.hs 47 + checkPersistBuildConfig, hunk ./Distribution/Simple/Configure.hs 123 - ( doesFileExist ) + ( doesFileExist, getModificationTime ) hunk ./Distribution/Simple/Configure.hs 158 --- |Read the 'localBuildInfoFile'. Error if it doesn't exist. +-- |Read the 'localBuildInfoFile'. Error if it doesn't exist. Also +-- fail if the file containing LocalBuildInfo is older than the .cabal +-- file, indicating that a re-configure is required. hunk ./Distribution/Simple/Configure.hs 179 +-- |Check that localBuildInfoFile is up-to-date with respect to the +-- .cabal file. +checkPersistBuildConfig :: FilePath -> IO () +checkPersistBuildConfig pkg_descr_file = do + t0 <- getModificationTime pkg_descr_file + t1 <- getModificationTime localBuildInfoFile + when (t0 > t1) $ + die (pkg_descr_file ++ " has been changed, please re-configure.") + hunk ./Distribution/Simple/Configure.hs 192 - hunk ./Distribution/Simple/Configure.hs 303 + pkgDescrFile = Nothing, hunk ./Distribution/Simple/LocalBuildInfo.hs 90 + pkgDescrFile :: Maybe FilePath, + -- ^ the filename containing the .cabal file, if available hunk ./Distribution/Simple.hs 87 -import Distribution.Simple.Configure(getPersistBuildConfig, maybeGetPersistBuildConfig, +import Distribution.Simple.Configure(getPersistBuildConfig, + maybeGetPersistBuildConfig, + checkPersistBuildConfig, hunk ./Distribution/Simple.hs 310 - pkg_descr0 <- maybe (confPkgDescr flags') (return . Right) mdescr + (mb_pd_file, pkg_descr0) <- confPkgDescr flags' hunk ./Distribution/Simple.hs 319 - localbuildinfo <- confHook hooks epkg_descr flags' + localbuildinfo0 <- confHook hooks epkg_descr flags' hunk ./Distribution/Simple.hs 321 + -- remember the .cabal filename if we know it + let localbuildinfo = localbuildinfo0{ pkgDescrFile = mb_pd_file } hunk ./Distribution/Simple.hs 328 - confPkgDescr :: ConfigFlags -> IO (Either GenericPackageDescription - PackageDescription) - confPkgDescr cfgflags = do - mdescr' <- readDesc hooks - case mdescr' of - Just descr -> return $ Right descr - Nothing -> do - pdfile <- defaultPackageDesc (configVerbose cfgflags) - ppd <- readPackageDescription (configVerbose cfgflags) pdfile - return (Left ppd) + confPkgDescr :: ConfigFlags + -> IO (Maybe FilePath, + Either GenericPackageDescription + PackageDescription) + confPkgDescr cfgflags = + case mdescr of + Just ppd -> return (Nothing, Right ppd) + Nothing -> do + mdescr' <- readDesc hooks + case mdescr' of + Just descr -> return (Nothing, Right descr) + Nothing -> do + pdfile <- defaultPackageDesc (configVerbose cfgflags) + ppd <- readPackageDescription (configVerbose cfgflags) pdfile + return (Just pdfile, Left ppd) hunk ./Distribution/Simple.hs 345 - lbi <- getPersistBuildConfig + lbi <- getBuildConfigIfUpToDate hunk ./Distribution/Simple.hs 356 - getPersistBuildConfig + getBuildConfigIfUpToDate hunk ./Distribution/Simple.hs 361 - getPersistBuildConfig + getBuildConfigIfUpToDate hunk ./Distribution/Simple.hs 366 - getPersistBuildConfig + getBuildConfigIfUpToDate hunk ./Distribution/Simple.hs 371 - getPersistBuildConfig + getBuildConfigIfUpToDate hunk ./Distribution/Simple.hs 390 - getPersistBuildConfig + getBuildConfigIfUpToDate hunk ./Distribution/Simple.hs 395 - getPersistBuildConfig + getBuildConfigIfUpToDate hunk ./Distribution/Simple.hs 413 - localbuildinfo <- getPersistBuildConfig + localbuildinfo <- getBuildConfigIfUpToDate hunk ./Distribution/Simple.hs 420 - getPersistBuildConfig + getBuildConfigIfUpToDate hunk ./Distribution/Simple.hs 425 - getPersistBuildConfig + getBuildConfigIfUpToDate hunk ./Distribution/Simple.hs 450 +getBuildConfigIfUpToDate :: IO LocalBuildInfo +getBuildConfigIfUpToDate = do + lbi <- getPersistBuildConfig + case pkgDescrFile lbi of + Nothing -> return () + Just pkg_descr_file -> checkPersistBuildConfig pkg_descr_file + return lbi + } Context: [Correct the spelling of mingw32 in os alias list Duncan Coutts **20071018195641 Doh! ] [refinement of fix for #1785: don't use xargs' -s option at all Simon Marlow **20071019124522] [don't fail if xxx_hsc_make.c is gone Ross Paterson **20071018164245 The non-GHC hsc2hs deletes it even if the compilation fails. ] [Use cpp-options rather than abusing ghc-options Duncan Coutts **20071017164914] [Add a "cpp-options:" field and use it for pre-processing .hs .hsc .chs files Duncan Coutts **20071017164747 This is for pre-processing Haskell modules, not for C code. We already have cc-options for that purpose. Up 'til now people have been abusing ghc-options for this purpose. Even Cabal itself was guilty of doing that. ] [Figure out if hsc2hs is using gcc or ghc as it's C compiler Duncan Coutts **20071017143108 and pass the appropriate flags on the basis of knowing that. This is a hack. What we should do longer term is make hsc2hs always use gcc as it's C compiler and have Cabal figure out the right flags to pass it, rather than using ghc to pass on the appropriate flags to gcc. ] [Change the handling of cpp & ghc flags for hsc2hs Duncan Coutts **20071016231652 The hsc2hs that comes with ghc uses ghc as the C compiler. This means we must escape the real cc flags. It also means we can ask ghc to add extra include dirs that we might need to find includes of dependent packages. This is a bit of a hack. In the longer term it'd be better for Cabal to collect the include dirs and cc options of dependent packages and to pass them explicitly itself. ] [Move ghcVerbosity function into GHC module to share code Duncan Coutts **20071014165730] [Note current development version number in release notes Duncan Coutts **20071012121835] [Update the TODO list, mostly removing things. Duncan Coutts **20071012121702 Most of these are duplicated by Trac bugs. We should try and get rid of this TODO file completely and just use Trac. ] [Add logging functions notice, info, debug functions and use them consistently Duncan Coutts **20071012113237 We previously had this kind of code all over the place: > when (verbosity >= verbose) > (putStrLn "some message") We now replace that with: > info verbosity "some message" Much nicer. ] [When parsing ghc-pkg output, only look at the first package.conf file for GlobalPackageDB and SpecificPackageDB, and all package.conf files for UserPackageDB. bjorn@bringert.net**20071016095254 Before, we would consider user packages when fulfilling dependencies for global installs. ghc-pkg will refuse to install packages globally if they use user packages. Thus, without this patch, global installs can fail when you have user packages installed. ] [Pass -c (silent create) to ar when verbosity < normal. bjorn@bringert.net**20071013220906] [Change --verbosity= option of SetupWrapper (cabal-setup) to --verbose=, since that is what the rest of Cabal uses. bjorn@bringert.net**20071013215617] [Pass -w -v0 to ghc when compiling Setup.{lhs,hs} in SetupWrapper when verbosity == silent. bjorn@bringert.net**20071013214820] [Update documentation on configurations Duncan Coutts **20071012015338 Describe the new syntax and make variuous changes to the description of the meaning. ] [Use -O2 for compiling .c files when we configure --enable-optimization Duncan Coutts **20071011223607 Seems a reasonable default behaviour. ] [Remove commented-out code. bjorn@bringert.net**20071006083615 Push to 1.2. ] [Rename parseDescription to parsePackageDescription. bjorn@bringert.net**20071006083354 This should be pushed to cabal-1.2 to make cabal-install work with 1.2. ] [Bump version number to 1.3 bjorn@bringert.net**20071005105412] [Fix GenericPrackageDescription pretty printing to make it parsable. It still does not include all information. bjorn@bringert.net**20071005102555] [Haddock comment for the available dependencies argument to finalizePackageDescription. bjorn@bringert.net**20071004134544] [FIX GHC bug #1785: use 2048 as the maximum command-line size Simon Marlow **20071018140500 Apparently Solaris sets a limit of 2048 here ] [Expose parseDescription. bjorn@bringert.net**20071005104554] [parameterise InstalledPackageInfo over the type of module names Simon Marlow **20071003114947 This is useful in GHC, we can instantiate InstalledPackageInfo to ModuleName and avoid lots of String<->FastString conversions. ] [Add extra-libs to shared library linking Clemens Fruhwirth **20070927123923] [Actually -stubdir only works well in ghc-6.8 due to -I search dir mess Duncan Coutts **20070926131843 In ghc-6.6 the Foo/Bar.hc files only #include "Bar_stub.h" rather than #include "Foo/Bar_stub.h". This means when we set the stubdir so that the _stub.h files don't sit next to the .hs file then the include search path is not right to find the _stub.h file. In ghc-6.8 this is fixed so that it adds the -stubdir path to the include search path when calling gcc. ] [The -stubdir flag is supported in ghc-6.6 not just 6.6.1 Duncan Coutts **20070926114223] [Improve error messages for failed sanity checks. Thomas Schilling **20070925144955] [Translate flat files into sectionized files, by duplicating global Thomas Schilling **20070925144921 dependecies into each non-empty section. The previous solution dumped them into the library section, even if it would have been empty otherwise. ] [Add -package-name to GHC invocation when linking DSOs Clemens Fruhwirth **20070926090025] [Be more fuzzy with os, arch and impl matching in conditions. Fixes bug #158. Duncan Coutts **20070925132608 Do all the comparisons case insensitively and add some OS aliases so that if os(windows) works if the System.Info.os is actually "mingw32". ] [Don't generate links when dependent docs not installed. Fixes bug #157. Duncan Coutts **20070924142520 Generates a warning rather than failing as before. ] [Fix warnings Ian Lynagh **20070923122921] [Fix pre-processing for executables Duncan Coutts **20070922105414 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. ] [Remove some now-unecessary cleaning that causes problems for haskell-src Ian Lynagh **20070920203257 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). ] [Move expensive conviguration actions inside branch where they're used Duncan Coutts **20070917085834 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.) ] [Note in .cabal file that we're using a custom build-type Duncan Coutts **20070917033959] [Pass on all the cabal-setup options to cabal, not just unrecognised ones Duncan Coutts **20070917025121 So for example -v and -w get passed on rather than swallowed by cabal-setup itself. ] [Put setup program and setup .o/.hi files into dist/setup Duncan Coutts **20070917024907 That way they get cleaned automatically and do not clutter the top dir. ] [Correct the verbosity range in the "--help" text Duncan Coutts **20070917024416 The correct range in 0--3, not 0--2 or 0--5 ] [look in odir for source and .hs files, not buildDir lbi Duncan Coutts **20070917145030 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. ] [Put _stub.{c|h} files under dist/ so they'll get cleaned. Fixes bug #154. Duncan Coutts **20070917123042 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. ] [Don't create empty data dirs. Fixes bug #153. Duncan Coutts **20070912113803 Patch contributed by Sven Panne. ] [Use confgurations to help build Cabal for ghc-6.2.x Duncan Coutts **20070912112934 Replacing a long-standing comment telling people how to do it manually. ] [Add a boring file Ian Lynagh **20070913203550] [Fix haddockDir Ian Lynagh **20070912133051] [Add htmlDirTemplate to inplaceDirs Ian Lynagh **20070912125749] [Add a --htmldir flag Ian Lynagh **20070912122145] [Don't forcibly append "pkgName (package pkg_descr)" to htmldir Ian Lynagh **20070911192814] [TAG 2007-09-06 Ian Lynagh **20070906212150] [use OPTIONS instead of OPTIONS_GHC for now, the latter doesn't work with GHC 6.2.x Simon Marlow **20070912105243] [warning police Simon Marlow **20070907140731] [Update D.S.GHC/Makefile.hs Clemens Fruhwirth **20070906213507] [Add shared library building to GHC module (also via Makefile) Clemens Fruhwirth **20070906213132] [fix type clash: Data.Version -> Distribution.Version Malcolm.Wallace@cs.york.ac.uk**20070906163051] [fix broken #ifdefs for nhc98 Malcolm.Wallace@cs.york.ac.uk**20070906161553] [spell nhc98-options correctly Malcolm.Wallace@cs.york.ac.uk**20070906150411] [TAG 1.2.0 Duncan Coutts **20070906121830] [Remove now-empty dependencies dir Duncan Coutts **20070906012144 Not needed since cabal-install moved to another repo. ] [note need to use -i when bootstrapping ghc, and update coders list Duncan Coutts **20070906012055] [Bump version number to 1.2.0 Duncan Coutts **20070906010337] [Fix haddock markup Duncan Coutts **20070906010221] [Use layout rather than braces {} for sections in our own .cabal file Duncan Coutts **20070906002844 Since we can and we want to set a good example. ] [Update changelog Duncan Coutts **20070906002539] [Update authors list in LICENSE and remove duplicate copyright file Duncan Coutts **20070906002235 We currently have 39 different authors, all those with a significant number of patches are listed as copyright holders in the LICENSE file. ] [Rewrite the parser for the configuration structure to allow laout or braces Duncan Coutts **20070905223609 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. ] [Remove unused helper function Duncan Coutts **20070903122408 Ok to remove, it never appeared in any release. ] [Oops, fix Distribution.Make Duncan Coutts **20070903122355] [Fix haddock markup Duncan Coutts **20070903113145 Thanks to int-e for reporting ] [Generalise build --ghc-option flag to --prog-option for any prog Duncan Coutts **20070903110658 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. ] [Make userSpecifyArgs update the args even if the prog is configured already Duncan Coutts **20070903104852] [Remove register --with-hc-pkg flag Duncan Coutts **20070903091038 It was just a hack for the benefit of ghc and we don't need it now. ] [Rename --prog-args to --prog-options Duncan Coutts **20070902170637 amd --prog-arg to --prog-arg and update the user guide. ] [Change --configure-option= to --configure-arg= Duncan Coutts *-20070902003334 For consitency with other flags. ] [Change --configure-option= to --configure-arg= Duncan Coutts **20070902003334 For consitency with other flags. ] [Pass --configure-option= options to configure in the right order Duncan Coutts **20070901173147 in the same order as they were passed to c