From duncan.coutts at worc.ox.ac.uk Fri Jun 1 05:27:25 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Jun 1 05:22:21 2007 Subject: [Gtk2hs-devel] [Gtk2hs-users] Problem compiling development version In-Reply-To: <37df87420705311936o1a5fb637i4150f22369dd5554@mail.gmail.com> References: <46564DCA.4010006@orcon.net.nz> <1180273682.6729.15.camel@localhost> <37df87420705271112l48873aaaxdd732c785aa6c64@mail.gmail.com> <1180349387.6729.35.camel@localhost> <1180558079.10129.4.camel@localhost> <37df87420705301635q562a5461wfbb5e88987253a1a@mail.gmail.com> <1180571482.10129.25.camel@localhost> <37df87420705302023h2dc6be36j35f2e940e7109f24@mail.gmail.com> <1180618214.10129.76.camel@localhost> <37df87420705311935r7c6eb1p8f121952517af19b@mail.gmail.com> <37df87420705311936o1a5fb637i4150f22369dd5554@mail.gmail.com> Message-ID: <1180690045.10129.84.camel@localhost> On Thu, 2007-05-31 at 22:36 -0400, Peter Gavin wrote: > Oops, I guess I hit the send button too early :) > > On 5/31/07, Peter Gavin wrote: > > Ok, so I've taken a look at the cabal sources, and I've decided to add > > a very simple way for preprocessors to specify dependecies. > > Basically, I'm going to add a field to the PreProcessor datatype: > > calcDependencies :: (FilePath, FilePath) -> Verbosity -> IO [Module], > > that returns the modules that should be preprocessed before the source > > file passed as the first argument. The only preprocessor that will > > really take advantage of this is the C2hs one, of course. Then the > > preprocessSources function will call calcDependencies > to build the dependency graph. > > How does that sound? That sounds sensible. I'm cc'ing the cabal-devel list which is the place to ask questions and get opinions and where patches should be sent for wider review by cabal hackers. Duncan From marco-oweber at gmx.de Sun Jun 3 16:54:03 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Jun 3 16:49:38 2007 Subject: copy / register / --gen-script and --destdir Message-ID: <20070603205403.GA3241@gmx.de> I can use ./setup copy --destdir to copy all hi files etc to some directory. But how do I register it then? Setting --prefix when using configure does'nt seem to adjust the register.sh using --gen-script I just can't add --destdir. What am I missing? Marc From duncan.coutts at worc.ox.ac.uk Sun Jun 3 18:26:58 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Jun 3 18:21:44 2007 Subject: copy / register / --gen-script and --destdir In-Reply-To: <1180909560.6210.46.camel@localhost> References: <20070603205403.GA3241@gmx.de> <1180909560.6210.46.camel@localhost> Message-ID: <1180909618.6210.48.camel@localhost> oops, sent to Marc without also cc'ing the list... On Sun, 2007-06-03 at 23:26 +0100, Duncan Coutts wrote: > On Sun, 2007-06-03 at 22:54 +0200, Marc Weber wrote: > > I can use ./setup copy --destdir to copy all hi files etc to some > > directory. > > > > But how do I register it then? > > Setting --prefix when using configure does'nt seem to adjust the > > register.sh > > using --gen-script I just can't add --destdir. > > > > What am I missing? > > Sounds like a bug to me. Can you file a bug report with all the exact > details of what you expected and what really happened. And if you > happened to send in a patch fixing said bug that'd be even better :-) > > Duncan From ross at soi.city.ac.uk Sun Jun 3 21:04:07 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Jun 3 20:59:39 2007 Subject: copy / register / --gen-script and --destdir In-Reply-To: <20070603205403.GA3241@gmx.de> References: <20070603205403.GA3241@gmx.de> Message-ID: <20070604010407.GA9025@soi.city.ac.uk> On Sun, Jun 03, 2007 at 10:54:03PM +0200, Marc Weber wrote: > I can use ./setup copy --destdir to copy all hi files etc to some > directory. > > But how do I register it then? > Setting --prefix when using configure does'nt seem to adjust the > register.sh > using --gen-script I just can't add --destdir. > > What am I missing? The docs a bit terse on this point, but copy --destdir isn't intended for registering on the same machine. It's for building binary packages, where you want to build an image of part of the root filesystem of the target machine, but place it inside a subdirectory on the build machine. The idea is to tar up that subtree, ship it to the target machine, unpack it there at the root and run register.sh. The register.sh script is supposed to be ignorant of the destdir. From duncan.coutts at worc.ox.ac.uk Mon Jun 4 06:33:00 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jun 4 06:27:44 2007 Subject: copy / register / --gen-script and --destdir In-Reply-To: <20070604010407.GA9025@soi.city.ac.uk> References: <20070603205403.GA3241@gmx.de> <20070604010407.GA9025@soi.city.ac.uk> Message-ID: <1180953180.6210.67.camel@localhost> On Mon, 2007-06-04 at 02:04 +0100, Ross Paterson wrote: > On Sun, Jun 03, 2007 at 10:54:03PM +0200, Marc Weber wrote: > > I can use ./setup copy --destdir to copy all hi files etc to some > > directory. > > > > But how do I register it then? > > Setting --prefix when using configure does'nt seem to adjust the > > register.sh > > using --gen-script I just can't add --destdir. > > > > What am I missing? > > The docs a bit terse on this point, but copy --destdir isn't intended > for registering on the same machine. It's for building binary packages, > where you want to build an image of part of the root filesystem of the > target machine, but place it inside a subdirectory on the build machine. > The idea is to tar up that subtree, ship it to the target machine, unpack > it there at the root and run register.sh. The register.sh script is > supposed to be ignorant of the destdir. Ah yes, quite right. The --destdir is like automake's "make install DESTDIR=$TMP/blah" feature. But using configure --prefix should change what register --gen-script produces, so if that's not happening then it's a bug I think. Duncan From duncan.coutts at worc.ox.ac.uk Mon Jun 4 06:59:06 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jun 4 06:53:50 2007 Subject: Cabal -extra-lib-dirs and -rpath, also framework-dirs In-Reply-To: References: Message-ID: <1180954746.22405.8.camel@localhost> On Sun, 2007-06-03 at 15:48 -0700, Ashley Yakeley wrote: > 1. It seems entries on the extra-lib-dirs line in cabal (GHC 6.6) are > not passed to the linker with -rpath. Instead, you have to do that in > ld-options with "-Wl,-rpath -Wl,mylibdir". The trouble is this is not > portable, as the Darwin (Mac OS X) linker doesn't accept the -rpath > option and (I think) simply uses all -L directories for the runtime path > or some clever thing. > > I recommend that either extra-lib-dirs be passed as -rpath (as > appropriate for the platform), or a new field such as "extra-rpath-dirs" > be added. Ugg. This is somewhat a can of worms. For one thing it doesn't work on windows, but also it's not necessarily what one always wants. For example building on one machine and deploying on another, if there are specific paths baked into the libraries/executables that might be intended to be on the standard dynamic linker path on the target machine. I think this issue needs a fair bit of thought before we go and implement something. We should see what other systems do etc. > 2. Cabal doesn't recognise "framework-dirs" as a field name, even though > it shows up in "ghc-pkg describe". Yes, cabal does not currently support that field. It probably should. The format used by ghc-pkg is quite similar to the cabal format, but not exactly the same, so don't be surprised by things appearing in one and not the other, or having slightly different names or meanings. Duncan From simonmarhaskell at gmail.com Mon Jun 4 07:06:18 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jun 4 07:01:54 2007 Subject: Cabal -extra-lib-dirs and -rpath, also framework-dirs In-Reply-To: <1180954746.22405.8.camel@localhost> References: <1180954746.22405.8.camel@localhost> Message-ID: <4663F22A.5060709@gmail.com> Duncan Coutts wrote: >> 2. Cabal doesn't recognise "framework-dirs" as a field name, even though >> it shows up in "ghc-pkg describe". > > Yes, cabal does not currently support that field. It probably should. > The format used by ghc-pkg is quite similar to the cabal format, but not > exactly the same, so don't be surprised by things appearing in one and > not the other, or having slightly different names or meanings. Yes, this is an important point. The ghc-pkg format is InstalledPackageInfo, see http://darcs.haskell.org/packages/Cabal/Distribution/InstalledPackageInfo.hs whereas the .cabal file contains a PackageDescription, which is quite a different beast. They happen to look similar and contain several fields in common, though. It might be reasonable for .cabal to have framework-dirs, but I don't know anything about frameworks... anyone? Cheers, Simon From marco-oweber at gmx.de Mon Jun 4 07:51:03 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Jun 4 07:46:48 2007 Subject: copy / register / --gen-script and --destdir In-Reply-To: <1180953180.6210.67.camel@localhost> References: <20070603205403.GA3241@gmx.de> <20070604010407.GA9025@soi.city.ac.uk> <1180953180.6210.67.camel@localhost> Message-ID: <20070604115103.GB10765@gmx.de> > The --destdir is like automake's "make install DESTDIR=$TMP/blah" > feature. But using configure --prefix should change what register > --gen-script produces, so if that's not happening then it's a bug I > think. Perhaps I should tell you what I am about to do. I want to register some cabal packages in the nix software distribution system. a -> b Package a depends on b and c ` c Right now when a is build nix does create a new package databse registering b and c. I think this can be done better by letting b and c have its own package database containing only their libs of their own. Then when a has to be build GHC_PACKAGE_DATABASE=: can be used to tell ghc where to find those libs. Thus my trouble is that I should copy the lib to /nix/store// Currently I'm using sed to prefix the right prefix using --gen-script .. Fixing cabal (if there is something to fix) does'nt have high priority for me right now. And in the long run I think we should think about writing something similar to scons (python build system) because some features should be written anyway (such as module dependency tracking ... ) At the moment I'm not sure how this should look like in detail. Thanks Marc From ross at soi.city.ac.uk Tue Jun 5 06:07:05 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Jun 5 06:02:34 2007 Subject: copy / register / --gen-script and --destdir In-Reply-To: <1180953180.6210.67.camel@localhost> References: <20070603205403.GA3241@gmx.de> <20070604010407.GA9025@soi.city.ac.uk> <1180953180.6210.67.camel@localhost> Message-ID: <20070605100704.GA3619@soi.city.ac.uk> On Mon, Jun 04, 2007 at 11:33:00AM +0100, Duncan Coutts wrote: > But using configure --prefix should change what register > --gen-script produces, so if that's not happening then it's a bug I > think. The input that the script gives to ghc-pkg is indeed altered by --prefix. From ross at soi.city.ac.uk Tue Jun 5 06:19:27 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Jun 5 06:14:55 2007 Subject: #140 (Cabal doesn't allow doc/html/ to be overridden) Message-ID: <20070605101927.GA5710@soi.city.ac.uk> igloo writes: > Distribution.Simple.LocalBuildInfo uses > > haddockPref pkg_descr > = foldl1 () [distPref, "doc", "html", pkgName (package pkg_descr)] > > and provides no way to override it. This should be a new field docdir > (or similar), and be overridable with a configure flag. haddockPref determines where the documentation is built; mkHaddockDir says where it is installed, currently $datadir/$datasubdir/doc/html/$pkg, where $datasubdir defaults to $pkgid. That default doesn't seem right in any case. Perhaps we want --docdir (defaulting to $prefix/share/doc on Unix and something else on Windows) --htmlsubdir (defaulting to $pkgid/html) From igloo at earth.li Tue Jun 5 13:44:08 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Jun 5 13:39:34 2007 Subject: #140 (Cabal doesn't allow doc/html/ to be overridden) In-Reply-To: <20070605101927.GA5710@soi.city.ac.uk> References: <20070605101927.GA5710@soi.city.ac.uk> Message-ID: <20070605174408.GA26124@matrix.chaos.earth.li> On Tue, Jun 05, 2007 at 11:19:27AM +0100, Ross Paterson wrote: > igloo writes: > > Distribution.Simple.LocalBuildInfo uses > > > > haddockPref pkg_descr > > = foldl1 () [distPref, "doc", "html", pkgName (package pkg_descr)] > > > > and provides no way to override it. This should be a new field docdir > > (or similar), and be overridable with a configure flag. > > haddockPref determines where the documentation is built; mkHaddockDir > says where it is installed Sorry, yes, you're right. I've updated the bug report. Thanks Ian From zunino at di.unipi.it Wed Jun 6 10:08:08 2007 From: zunino at di.unipi.it (Roberto Zunino) Date: Wed Jun 6 10:03:39 2007 Subject: HsColour integration (patch) In-Reply-To: <465DDEDE.7010601@di.unipi.it> References: <465DDEDE.7010601@di.unipi.it> Message-ID: <4666BFC8.3020607@di.unipi.it> Roberto Zunino wrote: > I am sending a patch[1] for integrating Cabal and HsColour + Haddock. Any comments on this? Can it be included in Cabal? Zun. From ross at soi.city.ac.uk Thu Jun 7 07:47:24 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jun 7 07:42:46 2007 Subject: Bugs and interface changes In-Reply-To: <20070526222639.GA1579@matrix.chaos.earth.li> References: <20070526222639.GA1579@matrix.chaos.earth.li> Message-ID: <20070607114724.GA4002@soi.city.ac.uk> On Sat, May 26, 2007 at 11:26:39PM +0100, Ian Lynagh wrote: > By the way, do bugs get automatically assigned to ijones? That doesn't > seem very useful to me. It would be useful to have a few more admins for the Hackage Trac. Could that be arranged? From nominolo at googlemail.com Sun Jun 10 09:44:14 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Jun 10 09:39:24 2007 Subject: Parsec as a Dependency? Message-ID: <916b84820706100644l749d4c81lcb29b0f61f250399@mail.gmail.com> Hi Caballers, now that .cabal files are getting a more complex syntax (due to configurations), I'd really like to use Parsec instead of lots of hand-written and hard to maintain parsing code. By getting rid of ReadP-based field parsing, we'd also get proper error messages for field values. At the Parsec homepage I says that it's now included by default in GHC, Hugs and NHC, so it'll most likely be present on any sufficiently recent system. What would be arguments against this proposal? / Thomas From simonmarhaskell at gmail.com Mon Jun 11 05:48:39 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jun 11 05:43:49 2007 Subject: Parsec as a Dependency? In-Reply-To: <916b84820706100644l749d4c81lcb29b0f61f250399@mail.gmail.com> References: <916b84820706100644l749d4c81lcb29b0f61f250399@mail.gmail.com> Message-ID: <466D1A77.8070506@gmail.com> Thomas Schilling wrote: > Hi Caballers, > > now that .cabal files are getting a more complex syntax (due to > configurations), I'd really like to use Parsec instead of lots of > hand-written and hard to maintain parsing code. By getting rid of > ReadP-based field parsing, we'd also get proper error messages for > field values. > > At the Parsec homepage I says that it's now included by default in > GHC, Hugs and NHC, so it'll most likely be present on any sufficiently > recent system. > > What would be arguments against this proposal? I've wondered about this myself. ReadP is quite annoying, I believe the only reason it was used originally was because it was in the base package, and hence didn't add any new dependencies. Unfortunately the portable version of ReadP is quite a pain to use. Adding parsec as a dependency is a big step - it would bring parsec into GHC's core packages, and force its distribution with other compilers too. I'm not completely against this, but we should explore alternatives first. Maybe a better solution would be to bring in a simple monadic parser combinator library. Malcolm Wallace has offered to relicense his Text.ParserCombinators.Poly from LGPL to BSD3 for use in Cabal, this might be a good option for us. Any other ideas? Cheers, Simon From ndmitchell at gmail.com Mon Jun 11 06:03:23 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Jun 11 05:58:31 2007 Subject: Parsec as a Dependency? In-Reply-To: <466D1A77.8070506@gmail.com> References: <916b84820706100644l749d4c81lcb29b0f61f250399@mail.gmail.com> <466D1A77.8070506@gmail.com> Message-ID: <404396ef0706110303n400a338aje4d22396f5ba2a37@mail.gmail.com> Hi > Adding parsec as a dependency is a big step - it would bring parsec into GHC's > core packages, and force its distribution with other compilers too. I'm not > completely against this, but we should explore alternatives first. If you choose to use something that isn't the best/most well known, eventually this debate will come around again with Poly vs Parsec. Couldn't you distribute Cabal by taking all required files from all packages (apart from base) and putting that in a tarball? I did this for Catch, and the distribution problems went from a severe headache to nothing. Thanks Neil From marco-oweber at gmx.de Mon Jun 11 07:16:58 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Jun 11 07:12:12 2007 Subject: Parsec as a Dependency? In-Reply-To: <466D1A77.8070506@gmail.com> References: <916b84820706100644l749d4c81lcb29b0f61f250399@mail.gmail.com> <466D1A77.8070506@gmail.com> Message-ID: <20070611111658.GA14657@gmx.de> > Adding parsec as a dependency is a big step - it would bring parsec into > GHC's core packages, and force its distribution with other compilers too. If this happens may I propose having a look at my small parsec patch allowing arbitrary token types not only chars ? Would this cause a big speed penalty? http://mawercer.de/marcweber/haskell/darcs/fparsec/ I've used this to create an experimental command line parser which works fine. Marc Weber From igloo at earth.li Mon Jun 11 07:29:07 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Jun 11 07:24:13 2007 Subject: HsColour integration (patch) In-Reply-To: <4666BFC8.3020607@di.unipi.it> References: <465DDEDE.7010601@di.unipi.it> <4666BFC8.3020607@di.unipi.it> Message-ID: <20070611112907.GA9822@matrix.chaos.earth.li> Hi Roberto, On Wed, Jun 06, 2007 at 04:08:08PM +0200, Roberto Zunino wrote: > Roberto Zunino wrote: > > >I am sending a patch[1] for integrating Cabal and HsColour + Haddock. > > Any comments on this? Can it be included in Cabal? I think Duncan, who usually deals with Cabal patches, is offline visiting family or something at the moment, so I expect he will take a look once he is back. I quickly skimmed the patch and it looked generally OK to me. One thing I did notice is this: let linkToHscolour = if hsColour then ["--source-module=src/%{FILE///-}.html" ,"--source-entity=src/%{FILE///-}.html#(line%{LINE})"] I assume by default haddock names each line, and hscolor doesn't? It would be nice to tweak hscolor so it also names the lines if so (but I don't think that needs to be done before the patch is accepted). Thanks Ian From igloo at earth.li Mon Jun 11 07:49:42 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Jun 11 07:44:49 2007 Subject: Parsec as a Dependency? In-Reply-To: <916b84820706100644l749d4c81lcb29b0f61f250399@mail.gmail.com> References: <916b84820706100644l749d4c81lcb29b0f61f250399@mail.gmail.com> Message-ID: <20070611114942.GB9822@matrix.chaos.earth.li> Hi Thomas, On Sun, Jun 10, 2007 at 03:44:14PM +0200, Thomas Schilling wrote: > > now that .cabal files are getting a more complex syntax (due to > configurations), I'd really like to use Parsec instead of lots of > hand-written and hard to maintain parsing code. By getting rid of > ReadP-based field parsing, we'd also get proper error messages for > field values. > > At the Parsec homepage I says that it's now included by default in > GHC, Hugs and NHC, As Simon said, unfortunately as of 6.8 it won't be included with GHC (as things stand, at least). alex+happy is another alternative, although I don't know off-hand if hugs/nhc/... can build them currently. Have you got a description of the grammar you want to parse? I'd like it if we could say if flag(foo) { other-modules: Foo Bar Baz ghc-options: -wibble } which needs some sort of layout rule for the module list. If we go for something like that then I wouldn't be surprised if this wasn't easiest to parse with just ad-hoc code, which would avoid any dependencies and give good error messages. The parser would only parse it down to something like Cond (Flag "foo) [Pair "other-modules:" "Foo\n Bar\n Baz\n", Pair "ghc-options:" "-wibble\n"] and these would then be further parsed by their own little parsers. Just looked at http://hackage.haskell.org/trac/hackage/wiki/CabalConfigurations I'd also suggest putting the top block of your example on that page in General { ... } (or some better name) and the next two in Flag: fps_in_base { ... } Flag: debug { ... } Thanks Ian From igloo at earth.li Mon Jun 11 07:52:43 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Jun 11 07:47:50 2007 Subject: Parsec as a Dependency? In-Reply-To: <20070611111658.GA14657@gmx.de> References: <916b84820706100644l749d4c81lcb29b0f61f250399@mail.gmail.com> <466D1A77.8070506@gmail.com> <20070611111658.GA14657@gmx.de> Message-ID: <20070611115243.GC9822@matrix.chaos.earth.li> On Mon, Jun 11, 2007 at 01:16:58PM +0200, Marc Weber wrote: > > If this happens may I propose having a look at my small parsec patch > allowing arbitrary token types not only chars ? I'm a bit confused as to what your patch does; parsec already supports arbitrary token types, doesn't it? e.g. parse :: GenParser tok () a -> SourceName -> [tok] -> Either ParseError a works with any token type tok. Thanks Ian From nominolo at googlemail.com Mon Jun 11 08:08:07 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Jun 11 08:03:13 2007 Subject: Parsec as a Dependency? In-Reply-To: <20070611114942.GB9822@matrix.chaos.earth.li> References: <916b84820706100644l749d4c81lcb29b0f61f250399@mail.gmail.com> <20070611114942.GB9822@matrix.chaos.earth.li> Message-ID: <916b84820706110508s6d972dcamfee73f25941adc13@mail.gmail.com> On 6/11/07, Ian Lynagh wrote: > > Hi Thomas, > > On Sun, Jun 10, 2007 at 03:44:14PM +0200, Thomas Schilling wrote: > > > > now that .cabal files are getting a more complex syntax (due to > > configurations), I'd really like to use Parsec instead of lots of > > hand-written and hard to maintain parsing code. By getting rid of > > ReadP-based field parsing, we'd also get proper error messages for > > field values. > > > > At the Parsec homepage I says that it's now included by default in > > GHC, Hugs and NHC, > > As Simon said, unfortunately as of 6.8 it won't be included with GHC (as > things stand, at least). > > alex+happy is another alternative, although I don't know off-hand if > hugs/nhc/... can build them currently. > > Have you got a description of the grammar you want to parse? > > I'd like it if we could say > if flag(foo) { > other-modules: Foo > Bar > Baz > ghc-options: -wibble > } > which needs some sort of layout rule for the module list. If we go for > something like that then I wouldn't be surprised if this wasn't easiest > to parse with just ad-hoc code, which would avoid any dependencies and > give good error messages. > > The parser would only parse it down to something like > > Cond (Flag "foo) [Pair "other-modules:" "Foo\n Bar\n Baz\n", > Pair "ghc-options:" "-wibble\n"] > > and these would then be further parsed by their own little parsers. > > > > Just looked at > http://hackage.haskell.org/trac/hackage/wiki/CabalConfigurations > > I'd also suggest putting the top block of your example on that page in > General { ... } > (or some better name) and the next two in > Flag: fps_in_base { ... } > Flag: debug { ... } The current syntax looks like this: Name: Foo Version: 0.1 ... Flag name { Description: ... } ... Library { Build-Depends: ... if os(freebsd) && flag(foo) { Build-Depends: ... } some-flag: ... } Executable name { ... } ... } I first parse it into the general syntactic constructs (field-description, section, or if-statement) and then transform it into something like an AST which then gets parsed into the existing back-end structure, depending on the flags and available dependencies. The code however is rather ugly and ad-hoc. But since we won't need the full parsec anyways, maybe i can extract some combinators and will be fine. /Thomas -- "Remember! Everytime you say 'Web 2.0' God kills a startup!" - userfriendly.org, Jul 31, 2006 From zunino at di.unipi.it Mon Jun 11 11:33:02 2007 From: zunino at di.unipi.it (Roberto Zunino) Date: Mon Jun 11 11:28:51 2007 Subject: HsColour integration (patch) In-Reply-To: <20070611112907.GA9822@matrix.chaos.earth.li> References: <465DDEDE.7010601@di.unipi.it> <4666BFC8.3020607@di.unipi.it> <20070611112907.GA9822@matrix.chaos.earth.li> Message-ID: <466D6B2E.5010609@di.unipi.it> Ian Lynagh wrote: > I think Duncan, who usually deals with Cabal patches, is offline > visiting family or something at the moment, so I expect he will take a > look once he is back. OK, thank you for the information. > I assume by default haddock names each line, and hscolor doesn't? It > would be nice to tweak hscolor so it also names the lines if so (but I > don't think that needs to be done before the patch is accepted). I already did this: check the latest release of hscolour. :-) The only non-released dependency is Haddock: darcs Haddock is needed for links to work. Zun. From marco-oweber at gmx.de Mon Jun 11 20:46:07 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Jun 11 20:41:21 2007 Subject: Parsec as a Dependency? In-Reply-To: <20070611115243.GC9822@matrix.chaos.earth.li> References: <916b84820706100644l749d4c81lcb29b0f61f250399@mail.gmail.com> <466D1A77.8070506@gmail.com> <20070611111658.GA14657@gmx.de> <20070611115243.GC9822@matrix.chaos.earth.li> Message-ID: <20070612004607.GA25271@gmx.de> > works with any token type tok. Sorry. You are right. You can customize the error position depending on token type. Eg when parsing command line arguments tracking a line number doesn't make sense. Some time has passed since having done this .. ;( Marc From igloo at earth.li Tue Jun 12 13:41:41 2007 From: igloo at earth.li (Ian Lynagh) Date: Tue Jun 12 13:36:45 2007 Subject: Parsec as a Dependency? In-Reply-To: <20070612004607.GA25271@gmx.de> References: <916b84820706100644l749d4c81lcb29b0f61f250399@mail.gmail.com> <466D1A77.8070506@gmail.com> <20070611111658.GA14657@gmx.de> <20070611115243.GC9822@matrix.chaos.earth.li> <20070612004607.GA25271@gmx.de> Message-ID: <20070612174141.GA31113@matrix.chaos.earth.li> On Tue, Jun 12, 2007 at 02:46:07AM +0200, Marc Weber wrote: > > works with any token type tok. > > You can customize the error position depending on token type. > > Eg when parsing command line arguments tracking a line number doesn't > make sense. Ah, OK. Parsec is maintained by Daan Leijen who AFAIK doesn't read this list, so it's probably best to send your patch to him. Thanks Ian From nominolo at googlemail.com Tue Jun 12 18:48:17 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Jun 12 18:43:23 2007 Subject: Test Cases for Configurations Message-ID: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> Hi, it's still a little work to do, but I think I'll be able to try and use Cabal configurations some time next week. Do you guys have any ideas what we could use as a good test case? The goal is to find out how well the current scheme applies to actual use cases (and if there are serious performance problems to await). / Thomas From sascha.boehme at gmx.de Wed Jun 13 02:52:15 2007 From: sascha.boehme at gmx.de (Sascha =?iso-8859-1?Q?B=F6hme?=) Date: Wed Jun 13 02:48:25 2007 Subject: setting up a chroot jail Message-ID: <20070613065215.GB4890@eloas> Hello, although my question may be out of topic, I kindly ask for your help. I am working on the Google summer of code project to enhance the HackageDB website, especially by a tool to automatically generate Haddock documentation. For this to work, it is necessary to set up a chroot jail, in which packages are unpacked, configured and Haddock documentation is build. Some packages also need to be build, which could include running untrustable code. Up to now, I considered several ideas to set up a chroot jail, but they all do not fully satisfy my needs or I could not test them on my machine. Here are my proposals for setting up a chroot environment: 1) use a hand-written script 2) use makejail, jail, jailkit (or a similar tool) 3) use debootstrap 4) use dpkg to install necessary debian packages My distribution is gentoo, which is why I did not test 3). However, I thought that 4) is suitable, although it's very tedious. In fact, it seems to me like rewriting parts of debian installers. Option 1) is just not maintainable. Finally, 2) seems to be of use just for servers like ssh or ftp. I haven't tested it, but I doubt it will work in an environment with several different applications like ghc, haddock, cpphs, happy, ... Does anyone have an idea how to (automatically, maintainably) set up a chroot jail for this particular situation? I'm grateful for any help. Thanks, Sascha From marco-oweber at gmx.de Wed Jun 13 15:55:49 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Wed Jun 13 15:51:01 2007 Subject: setting up a chroot jail In-Reply-To: <20070613065215.GB4890@eloas> References: <20070613065215.GB4890@eloas> Message-ID: <20070613195549.GA28384@gmx.de> > [..] > 4) use dpkg to install necessary debian packages > 5) Use the gentoo portage sandbox ( thus generate a gentoo package for each documention package (will work on gentoo only ) 6) use uml (use mode linux) and any distro you like (would need much more disk space) - would be overkill but would work fine.. Sorry. I have no experience with that. The t2-project.org does have somehting simlar as well (don't know which kind though) Marc Weber From stefanor at cox.net Wed Jun 13 18:07:14 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Jun 13 18:02:14 2007 Subject: setting up a chroot jail In-Reply-To: <20070613065215.GB4890@eloas> References: <20070613065215.GB4890@eloas> Message-ID: <20070613220714.GA2966@localhost.localdomain> On Wed, Jun 13, 2007 at 08:52:15AM +0200, Sascha B?hme wrote: > Hello, > > although my question may be out of topic, I kindly ask for your help. > > I am working on the Google summer of code project to enhance the > HackageDB website, especially by a tool to automatically generate > Haddock documentation. For this to work, it is necessary to set up a > chroot jail, in which packages are unpacked, configured and Haddock > documentation is build. Some packages also need to be build, which could > include running untrustable code. > > Up to now, I considered several ideas to set up a chroot jail, but they > all do not fully satisfy my needs or I could not test them on my machine. > > Here are my proposals for setting up a chroot environment: > > 1) use a hand-written script > > 2) use makejail, jail, jailkit (or a similar tool) > > 3) use debootstrap > > 4) use dpkg to install necessary debian packages > > My distribution is gentoo, which is why I did not test 3). However, I I definitely recall hearing debootstrap runs on Solaris. Gentoo, being still a Linux/glibc system, is thus almost certainly supported. Stefan From simonmarhaskell at gmail.com Thu Jun 14 06:18:54 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jun 14 06:13:53 2007 Subject: Test Cases for Configurations In-Reply-To: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> Message-ID: <4671160E.2050305@gmail.com> Thomas Schilling wrote: > it's still a little work to do, but I think I'll be able to try and use > Cabal configurations some time next week. Do you guys have any ideas > what we could use as a good test case? > > The goal is to find out how well the current scheme applies to actual > use cases (and if there are serious performance problems to await). Some suggestions: - the base package has a lot of goop in its Setup script, I really hope that all, or at least most, of it can be done using configurations - we have a few packages that want to do conditional dependencies. e.g. HGL wants to depend on either Win32 or X11. - IIRC, gtk2hs has a complex structure that will need a lot of conditional stuff in its .cabal file. Duncan will tell you more. - take a look at the old discussion on libraries@haskell.org; there were lots of use cases discussed there. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Thu Jun 14 13:15:24 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jun 14 13:10:59 2007 Subject: setting up a chroot jail In-Reply-To: <20070613195549.GA28384@gmx.de> References: <20070613065215.GB4890@eloas> <20070613195549.GA28384@gmx.de> Message-ID: <1181841324.5026.45.camel@localhost> On Wed, 2007-06-13 at 21:55 +0200, Marc Weber wrote: > > [..] > > 4) use dpkg to install necessary debian packages > > > > 5) Use the gentoo portage sandbox ( thus generate a gentoo package for > each documention package (will work on gentoo only ) The gentoo sandbox program does not mean one has to generate gentoo packages. It's a fairly self contained program. Note that the sandbox is not a chroot jail. It's kind of a supervisor for child processes that enforces a policy (given in a config file) for access to the file system. The gentoo package builder tool uses that to allow a build process to have read only access to the entire file system and write access to just the build directory (and sub-directories). As I understand it, it works using the linux kernel's ptrace mechanism to intercept and check syscalls against the security policy. I'm sure sandbox works on any linux system, not just gentoo, so it might be a good solution for HaskageDB. I expect it'd use more or less the same kind of security policy that the gentoo package build tools use, ie read only to the whole system and read/write for the specific build directory (and directory where the installed image/docs is put). Duncan From duncan.coutts at worc.ox.ac.uk Thu Jun 14 13:23:40 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jun 14 13:19:14 2007 Subject: HsColour integration (patch) In-Reply-To: <20070611112907.GA9822@matrix.chaos.earth.li> References: <465DDEDE.7010601@di.unipi.it> <4666BFC8.3020607@di.unipi.it> <20070611112907.GA9822@matrix.chaos.earth.li> Message-ID: <1181841820.5026.49.camel@localhost> On Mon, 2007-06-11 at 12:29 +0100, Ian Lynagh wrote: > Hi Roberto, > > On Wed, Jun 06, 2007 at 04:08:08PM +0200, Roberto Zunino wrote: > > Roberto Zunino wrote: > > > > >I am sending a patch[1] for integrating Cabal and HsColour + Haddock. > > > > Any comments on this? Can it be included in Cabal? > > I think Duncan, who usually deals with Cabal patches, is offline > visiting family or something at the moment, so I expect he will take a > look once he is back. If Ian says it's ok, I'm sure I'll say the same thing :-). Yes, I'll look at it in detail when I get back in about 12 days time. Duncan From duncan.coutts at worc.ox.ac.uk Thu Jun 14 13:27:57 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Jun 14 13:23:30 2007 Subject: Test Cases for Configurations In-Reply-To: <4671160E.2050305@gmail.com> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <4671160E.2050305@gmail.com> Message-ID: <1181842078.5026.54.camel@localhost> On Thu, 2007-06-14 at 11:18 +0100, Simon Marlow wrote: > Thomas Schilling wrote: > > > it's still a little work to do, but I think I'll be able to try and use > > Cabal configurations some time next week. Do you guys have any ideas > > what we could use as a good test case? > > > > The goal is to find out how well the current scheme applies to actual > > use cases (and if there are serious performance problems to await). > > Some suggestions: > > - the base package has a lot of goop in its Setup script, I really hope > that all, or at least most, of it can be done using configurations > > - we have a few packages that want to do conditional dependencies. e.g. > HGL wants to depend on either Win32 or X11. > > - IIRC, gtk2hs has a complex structure that will need a lot of conditional > stuff in its .cabal file. Duncan will tell you more. Unfortunately there's still a lot of work before Gtk2Hs is ready to be cabalised. Cabal configurations is a major piece of the puzzle though. But sadly there are too many other bits before Gtk2Hs would be a suitable test case for configurations. A cut down model of Gtk2Hs might work though, ie a bunch of .cabal files modelling the various bits of Gtk2Hs, just without any of the actual source code. > - take a look at the old discussion on libraries@haskell.org; there were > lots of use cases discussed there. Many related to fps/bytestring being included in the base package or not. Duncan From nominolo at googlemail.com Thu Jun 14 17:21:19 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Jun 14 17:16:19 2007 Subject: Test Cases for Configurations In-Reply-To: <1181842078.5026.54.camel@localhost> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <4671160E.2050305@gmail.com> <1181842078.5026.54.camel@localhost> Message-ID: <37A52230-C903-41B3-B44F-D12E22F9A449@googlemail.com> On 14 jun 2007, at 19.27, Duncan Coutts wrote: > On Thu, 2007-06-14 at 11:18 +0100, Simon Marlow wrote: >> Thomas Schilling wrote: >> >>> it's still a little work to do, but I think I'll be able to try >>> and use >>> Cabal configurations some time next week. Do you guys have any >>> ideas >>> what we could use as a good test case? >>> >>> The goal is to find out how well the current scheme applies to >>> actual >>> use cases (and if there are serious performance problems to await). >> >> Some suggestions: >> >> - the base package has a lot of goop in its Setup script, I >> really hope >> that all, or at least most, of it can be done using >> configurations >> >> - we have a few packages that want to do conditional >> dependencies. e.g. >> HGL wants to depend on either Win32 or X11. >> >> - IIRC, gtk2hs has a complex structure that will need a lot of >> conditional >> stuff in its .cabal file. Duncan will tell you more. > > Unfortunately there's still a lot of work before Gtk2Hs is ready to be > cabalised. Cabal configurations is a major piece of the puzzle though. > But sadly there are too many other bits before Gtk2Hs would be a > suitable test case for configurations. > > A cut down model of Gtk2Hs might work though, ie a bunch of .cabal > files > modelling the various bits of Gtk2Hs, just without any of the actual > source code. > >> - take a look at the old discussion on libraries@haskell.org; >> there were >> lots of use cases discussed there. > > Many related to fps/bytestring being included in the base package or > not. Is there some centralized documentation of these changes? Or should I just browse through the mailing lists? E.g., it looks like GHC doesn't have a .cabal file yet, so I'd have to manually translate to the Makefile, which I presume would be a major undertaking. Same applies for gtk2hs, whose ugliness I had to experience earlier. / Thomas From ross at soi.city.ac.uk Thu Jun 14 19:26:36 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Jun 14 19:21:33 2007 Subject: Test Cases for Configurations In-Reply-To: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> Message-ID: <20070614232636.GA7915@soi.city.ac.uk> On Wed, Jun 13, 2007 at 12:48:17AM +0200, Thomas Schilling wrote: > it's still a little work to do, but I think I'll be able to try and > use Cabal configurations some time next week. Do you guys have any > ideas what we could use as a good test case? > > The goal is to find out how well the current scheme applies to actual > use cases (and if there are serious performance problems to await). As Simon mentioned, there's HGL depending on either unix or Win32. The fps package was incorporated into base-2.0, so packages like binary, bzlib, zlib, darcs-graph or hmp3 could depend on base >= 2.0 or (base < 2.0 and fps). The html package was split off from base-2.0. For this reason HAppS has two variants of its Cabal file, which could be combined under configurations. Similarly lambdaFeed could depend on base < 2.0 or (base >= 2.0 and html). The above are all in HackageDB. The HEAD has a few more examples: Several packages are split off from base (but its version number hasn't been incremented yet, so you can't use that). The process package has a Setup.hs that exists only to drop the System.Process module for implementations other than GHC. The time package has a Setup.hs that adds a dependency on Win32 if the platform is Windows. From bringert at cs.chalmers.se Fri Jun 15 05:31:56 2007 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Fri Jun 15 05:25:22 2007 Subject: Test Cases for Configurations In-Reply-To: <20070614232636.GA7915@soi.city.ac.uk> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> Message-ID: <1E2E98F8-8A46-4EBC-8F7E-AE54D955E82B@cs.chalmers.se> On Jun 15, 2007, at 1:26 , Ross Paterson wrote: > On Wed, Jun 13, 2007 at 12:48:17AM +0200, Thomas Schilling wrote: >> it's still a little work to do, but I think I'll be able to try and >> use Cabal configurations some time next week. Do you guys have any >> ideas what we could use as a good test case? >> >> The goal is to find out how well the current scheme applies to actual >> use cases (and if there are serious performance problems to await). > > As Simon mentioned, there's HGL depending on either unix or Win32. > > The fps package was incorporated into base-2.0, so packages like > binary, > bzlib, zlib, darcs-graph or hmp3 could depend on base >= 2.0 or > (base < > 2.0 and fps). > > The html package was split off from base-2.0. For this reason HAppS > has two variants of its Cabal file, which could be combined under > configurations. Similarly lambdaFeed could depend on base < 2.0 or > (base >= 2.0 and html). > > The above are all in HackageDB. The HEAD has a few more examples: > > Several packages are split off from base (but its version number > hasn't > been incremented yet, so you can't use that). > > The process package has a Setup.hs that exists only to drop the > System.Process module for implementations other than GHC. > > The time package has a Setup.hs that adds a dependency on Win32 if the > platform is Windows. The unix-compat package depends on the unix package when not compiled on Windows, using Setup.lhs and CPP hacks. More packages with the usual base/fps thing: cgi, fastcgi, tar, htar, hope. /Bj?rn From igloo at earth.li Fri Jun 15 07:53:13 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Jun 15 07:48:06 2007 Subject: Test Cases for Configurations In-Reply-To: <20070614232636.GA7915@soi.city.ac.uk> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> Message-ID: <20070615115313.GA28048@matrix.chaos.earth.li> On Fri, Jun 15, 2007 at 12:26:36AM +0100, Ross Paterson wrote: > > The process package has a Setup.hs that exists only to drop the > System.Process module for implementations other than GHC. That's not something that we want to be able to fix with configurations, though. We need to either implement all the functionality for all the implementations or to split the package up. Thanks Ian From ndmitchell at gmail.com Fri Jun 15 07:56:41 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jun 15 07:51:35 2007 Subject: Test Cases for Configurations In-Reply-To: <20070615115313.GA28048@matrix.chaos.earth.li> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> <20070615115313.GA28048@matrix.chaos.earth.li> Message-ID: <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> Hi Ian, > That's not something that we want to be able to fix with configurations, > though. We need to either implement all the functionality for all the > implementations or to split the package up. I disagree. I have a library which provides two modules, one for compilers without multi-parameter type classes, and both for those with them. I want this to be one library, but I want the modules exported to vary based on the compiler being used. Since the library is small, splitting it up would be a big pain. Thanks Neil From igloo at earth.li Fri Jun 15 08:04:29 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Jun 15 07:59:22 2007 Subject: Test Cases for Configurations In-Reply-To: <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> <20070615115313.GA28048@matrix.chaos.earth.li> <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> Message-ID: <20070615120428.GA28628@matrix.chaos.earth.li> On Fri, Jun 15, 2007 at 12:56:41PM +0100, Neil Mitchell wrote: > > >That's not something that we want to be able to fix with configurations, > >though. We need to either implement all the functionality for all the > >implementations or to split the package up. > > I disagree. I have a library which provides two modules, one for > compilers without multi-parameter type classes, and both for those > with them. I want this to be one library, but I want the modules > exported to vary based on the compiler being used. Since the library > is small, splitting it up would be a big pain. I thought we'd all agreed that a library package should always export the same modules (and class, functions, type signatures etc), so that if foo depends on bar and you have bar installed then you know that you can build foo. In fact, I thought you were one of the people arguing in favour of this for the base package! Thanks Ian From ndmitchell at gmail.com Fri Jun 15 08:09:45 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jun 15 08:04:39 2007 Subject: Test Cases for Configurations In-Reply-To: <20070615120428.GA28628@matrix.chaos.earth.li> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> <20070615115313.GA28048@matrix.chaos.earth.li> <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> <20070615120428.GA28628@matrix.chaos.earth.li> Message-ID: <404396ef0706150509mce00d5dtdeef9ade265ef22a@mail.gmail.com> Hi > I thought we'd all agreed that a library package should always export > the same modules (and class, functions, type signatures etc), so that if > foo depends on bar and you have bar installed then you know that you can > build foo. > > In fact, I thought you were one of the people arguing in favour of this > for the base package! I was, for the base package. I want other people to obey these rules, but occasionally I want to violate them :) I'm not sure if in general it should be possible to change the export list. Perhaps we can rely on a large number of evil stares to stop this being common practice, and yet permit it occasionally. One thing I would like is given a package _data, which provides a data type, and a package _class which provides a class and various instances, I'd like to write in the _class cabal file: #if has _data module Class.InstanceForData #endif Perhaps configurations can support that? Thanks Neil From nominolo at googlemail.com Fri Jun 15 09:06:07 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Jun 15 09:01:07 2007 Subject: Test Cases for Configurations In-Reply-To: <404396ef0706150509mce00d5dtdeef9ade265ef22a@mail.gmail.com> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> <20070615115313.GA28048@matrix.chaos.earth.li> <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> <20070615120428.GA28628@matrix.chaos.earth.li> <404396ef0706150509mce00d5dtdeef9ade265ef22a@mail.gmail.com> Message-ID: On 15 jun 2007, at 14.09, Neil Mitchell wrote: > Hi > >> I thought we'd all agreed that a library package should always export >> the same modules (and class, functions, type signatures etc), so >> that if >> foo depends on bar and you have bar installed then you know that >> you can >> build foo. >> >> In fact, I thought you were one of the people arguing in favour of >> this >> for the base package! > > I was, for the base package. I want other people to obey these rules, > but occasionally I want to violate them :) > > I'm not sure if in general it should be possible to change the export > list. Perhaps we can rely on a large number of evil stares to stop > this being common practice, and yet permit it occasionally. > > One thing I would like is given a package _data, which provides a data > type, and a package _class which provides a class and various > instances, I'd like to write in the _class cabal file: > > #if has _data > module Class.InstanceForData > #endif > > Perhaps configurations can support that? > You mean like this? Name: demo Cabal-version: >= 1.3 Description: This is a test file with a description longer than two lines. flag Debug { Description: Enable debug information Default: False } library { build-depends: blub exposed-modules: Demo.Main, Demo if flag(debug) { build-depends: hunit ghc-options: -DDEBUG exposed-modules: Demo.Internal } } executable foo-bar { Main-is: Foo.hs } Of course in this case we'd need to add some flags to the version number, to indicate, that tho installed version has a certain feature enabled. This could be solved with a different package name of course, but I think it should be easy to add tags to a package version number: if flag(debug) { build-depends: hunit ghc-options: -DDEBUG tag: debug exposed-modules: Demo.Internal } Testing for the tag is (almost) already supported: build-depends: demo >= 1.1-debug, It should be used often, but it could if necessary. From ndmitchell at gmail.com Fri Jun 15 09:11:34 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Jun 15 09:06:27 2007 Subject: Test Cases for Configurations In-Reply-To: References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> <20070615115313.GA28048@matrix.chaos.earth.li> <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> <20070615120428.GA28628@matrix.chaos.earth.li> <404396ef0706150509mce00d5dtdeef9ade265ef22a@mail.gmail.com> Message-ID: <404396ef0706150611o5ecf2e1ek72f81e3232da0958@mail.gmail.com> Hi Yes, that's much better than what I was thinking! It also allows me to write my library and provide (or not) the flag when using GHC - so I can explicitly choose whether to require the extra features or not. Thanks Neil On 6/15/07, Thomas Schilling wrote: > > On 15 jun 2007, at 14.09, Neil Mitchell wrote: > > > Hi > > > >> I thought we'd all agreed that a library package should always export > >> the same modules (and class, functions, type signatures etc), so > >> that if > >> foo depends on bar and you have bar installed then you know that > >> you can > >> build foo. > >> > >> In fact, I thought you were one of the people arguing in favour of > >> this > >> for the base package! > > > > I was, for the base package. I want other people to obey these rules, > > but occasionally I want to violate them :) > > > > I'm not sure if in general it should be possible to change the export > > list. Perhaps we can rely on a large number of evil stares to stop > > this being common practice, and yet permit it occasionally. > > > > One thing I would like is given a package _data, which provides a data > > type, and a package _class which provides a class and various > > instances, I'd like to write in the _class cabal file: > > > > #if has _data > > module Class.InstanceForData > > #endif > > > > Perhaps configurations can support that? > > > > You mean like this? > > Name: demo > Cabal-version: >= 1.3 > > Description: This is a test file > with a description longer than two lines. > > flag Debug { > Description: Enable debug information > Default: False > } > > library { > build-depends: blub > exposed-modules: Demo.Main, Demo > > if flag(debug) { > build-depends: hunit > ghc-options: -DDEBUG > exposed-modules: Demo.Internal > } > } > > executable foo-bar { > Main-is: Foo.hs > } > > Of course in this case we'd need to add some flags to the version > number, to indicate, that tho installed version has a certain feature > enabled. > > This could be solved with a different package name of course, but I > think it should be easy to add tags to a package version number: > > if flag(debug) { > build-depends: hunit > ghc-options: -DDEBUG > tag: debug > exposed-modules: Demo.Internal > } > > Testing for the tag is (almost) already supported: > > build-depends: demo >= 1.1-debug, > > It should be used often, but it could if necessary. > > From nominolo at googlemail.com Fri Jun 15 09:25:50 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Jun 15 09:20:47 2007 Subject: Test Cases for Configurations In-Reply-To: <404396ef0706150611o5ecf2e1ek72f81e3232da0958@mail.gmail.com> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> <20070615115313.GA28048@matrix.chaos.earth.li> <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> <20070615120428.GA28628@matrix.chaos.earth.li> <404396ef0706150509mce00d5dtdeef9ade265ef22a@mail.gmail.com> <404396ef0706150611o5ecf2e1ek72f81e3232da0958@mail.gmail.com> Message-ID: I wrote: >> It should be used often, but it could if necessary. I meant to write: should _not_ /Thomas From igloo at earth.li Fri Jun 15 10:06:18 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Jun 15 10:01:22 2007 Subject: Test Cases for Configurations In-Reply-To: References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> <20070615115313.GA28048@matrix.chaos.earth.li> <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> <20070615120428.GA28628@matrix.chaos.earth.li> <404396ef0706150509mce00d5dtdeef9ade265ef22a@mail.gmail.com> Message-ID: <20070615140618.GA29814@matrix.chaos.earth.li> On Fri, Jun 15, 2007 at 03:06:07PM +0200, Thomas Schilling wrote: > > On 15 jun 2007, at 14.09, Neil Mitchell wrote: > > >this being common practice, and yet permit it occasionally. > > > >One thing I would like is given a package _data, which provides a data > >type, and a package _class which provides a class and various > >instances, I'd like to write in the _class cabal file: > > > >#if has _data > > module Class.InstanceForData > >#endif > > > >Perhaps configurations can support that? This has the same problem, in that different versions of the same package provide different things. Also, if you install _class first and _data second then you don't get Class.InstanceForData, whereas installing them the other way round you do. > Of course in this case we'd need to add some flags to the version > number, to indicate, that tho installed version has a certain feature > enabled. > > This could be solved with a different package name of course, but I > think it should be easy to add tags to a package version number: > > if flag(debug) { > build-depends: hunit > ghc-options: -DDEBUG > tag: debug > exposed-modules: Demo.Internal > } One thing I have considered proposing is rather than just exposed-modules: ... other-modules: ... we could have (I'm not particularly advocating this syntax): modules: ... modules[testing]: ... modules[internal]: ... (you can put any string inside [...]) and you can then, in another package, say depends: foo[testing,internal] > Testing for the tag is (almost) already supported: > > build-depends: demo >= 1.1-debug, IIRC tags are designed to be ignored when comparing version numbers, so this also has the same problem. Thanks Ian From igloo at earth.li Fri Jun 15 10:17:06 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Jun 15 10:12:00 2007 Subject: Test Cases for Configurations In-Reply-To: <20070615140618.GA29814@matrix.chaos.earth.li> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> <20070615115313.GA28048@matrix.chaos.earth.li> <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> <20070615120428.GA28628@matrix.chaos.earth.li> <404396ef0706150509mce00d5dtdeef9ade265ef22a@mail.gmail.com> <20070615140618.GA29814@matrix.chaos.earth.li> Message-ID: <20070615141706.GA30418@matrix.chaos.earth.li> On Fri, Jun 15, 2007 at 03:06:18PM +0100, Ian Lynagh wrote: > > This has the same problem, in that different versions of the same > package provide different things. I mean "the same version of the same package can provide different things". Thanks Ian From simonmarhaskell at gmail.com Mon Jun 18 04:16:10 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jun 18 04:10:58 2007 Subject: Test Cases for Configurations In-Reply-To: <20070615140618.GA29814@matrix.chaos.earth.li> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> <20070615115313.GA28048@matrix.chaos.earth.li> <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> <20070615120428.GA28628@matrix.chaos.earth.li> <404396ef0706150509mce00d5dtdeef9ade265ef22a@mail.gmail.com> <20070615140618.GA29814@matrix.chaos.earth.li> Message-ID: <46763F4A.2090306@gmail.com> Ian Lynagh wrote: > On Fri, Jun 15, 2007 at 03:06:07PM +0200, Thomas Schilling wrote: >> On 15 jun 2007, at 14.09, Neil Mitchell wrote: >> >>> this being common practice, and yet permit it occasionally. >>> >>> One thing I would like is given a package _data, which provides a data >>> type, and a package _class which provides a class and various >>> instances, I'd like to write in the _class cabal file: >>> >>> #if has _data >>> module Class.InstanceForData >>> #endif >>> >>> Perhaps configurations can support that? > > This has the same problem, in that different versions of the same > package provide different things. > > Also, if you install _class first and _data second then you don't get > Class.InstanceForData, whereas installing them the other way round you > do. > >> Of course in this case we'd need to add some flags to the version >> number, to indicate, that tho installed version has a certain feature >> enabled. >> >> This could be solved with a different package name of course, but I >> think it should be easy to add tags to a package version number: >> >> if flag(debug) { >> build-depends: hunit >> ghc-options: -DDEBUG >> tag: debug >> exposed-modules: Demo.Internal >> } > > One thing I have considered proposing is rather than just > > exposed-modules: ... > other-modules: ... > > we could have (I'm not particularly advocating this syntax): > > modules: ... > modules[testing]: ... > modules[internal]: ... A simpler way to solve this problem is to have two packages, with the first package (foo-internal) exporting all the modules, and the second (foo) re-exposing just the non-internal modules. We don't currently have support for re-exposing, but it has lots of uses and it shouldn't be too hard to add (to GHC, at least). Perhaps it's not quite as nice, though: the foo-internal package shows up in your ghc-pkg list, and you need two separate Cabal packages (although good support for working with multiple packages is something we should have too). Cheers, Simon From igloo at earth.li Mon Jun 18 05:57:30 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Jun 18 05:52:15 2007 Subject: Test Cases for Configurations In-Reply-To: <46763F4A.2090306@gmail.com> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> <20070615115313.GA28048@matrix.chaos.earth.li> <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> <20070615120428.GA28628@matrix.chaos.earth.li> <404396ef0706150509mce00d5dtdeef9ade265ef22a@mail.gmail.com> <20070615140618.GA29814@matrix.chaos.earth.li> <46763F4A.2090306@gmail.com> Message-ID: <20070618095730.GA21372@matrix.chaos.earth.li> On Mon, Jun 18, 2007 at 09:16:10AM +0100, Simon Marlow wrote: > > > > modules: ... > > modules[testing]: ... > > modules[internal]: ... > > A simpler way to solve this problem is to have two packages, with the first > package (foo-internal) exporting all the modules, and the second (foo) > re-exposing just the non-internal modules. We don't currently have support > for re-exposing, but it has lots of uses and it shouldn't be too hard to > add (to GHC, at least). > > Perhaps it's not quite as nice, though: the foo-internal package shows up > in your ghc-pkg list, and you need two separate Cabal packages (although > good support for working with multiple packages is something we should have > too). It also means that none of your internal modules can depend on any of your normal modules. (I'm not really convinced it's simpler either) Thanks Ian From simonmarhaskell at gmail.com Mon Jun 18 08:51:06 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Jun 18 08:45:52 2007 Subject: Test Cases for Configurations In-Reply-To: <20070618095730.GA21372@matrix.chaos.earth.li> References: <3AD1697B-F8B7-41FA-AA89-C5F585BC5512@googlemail.com> <20070614232636.GA7915@soi.city.ac.uk> <20070615115313.GA28048@matrix.chaos.earth.li> <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> <20070615120428.GA28628@matrix.chaos.earth.li> <404396ef0706150509mce00d5dtdeef9ade265ef22a@mail.gmail.com> <20070615140618.GA29814@matrix.chaos.earth.li> <46763F4A.2090306@gmail.com> <20070618095730.GA21372@matrix.chaos.earth.li> Message-ID: <46767FBA.7050600@gmail.com> Ian Lynagh wrote: > On Mon, Jun 18, 2007 at 09:16:10AM +0100, Simon Marlow wrote: >>> modules: ... >>> modules[testing]: ... >>> modules[internal]: ... >> A simpler way to solve this problem is to have two packages, with the first >> package (foo-internal) exporting all the modules, and the second (foo) >> re-exposing just the non-internal modules. We don't currently have support >> for re-exposing, but it has lots of uses and it shouldn't be too hard to >> add (to GHC, at least). >> >> Perhaps it's not quite as nice, though: the foo-internal package shows up >> in your ghc-pkg list, and you need two separate Cabal packages (although >> good support for working with multiple packages is something we should have >> too). > > It also means that none of your internal modules can depend on any of > your normal modules. Sure they can - the foo-internal package would contain all the modules (internal + external), but the foo package would only re-expose some of them. > (I'm not really convinced it's simpler either) Simpler in the sense of not adding new syntax and functionality to Cabal (well ok, it does add some functionality, because Cabal needs to know which modules are being re-exposed). Cheers, Simon From igloo at earth.li Mon Jun 18 09:15:25 2007 From: igloo at earth.li (Ian Lynagh) Date: Mon Jun 18 09:10:15 2007 Subject: Test Cases for Configurations In-Reply-To: <46767FBA.7050600@gmail.com> References: <20070614232636.GA7915@soi.city.ac.uk> <20070615115313.GA28048@matrix.chaos.earth.li> <404396ef0706150456w292b24aclb8a9ec68e2c458b3@mail.gmail.com> <20070615120428.GA28628@matrix.chaos.earth.li> <404396ef0706150509mce00d5dtdeef9ade265ef22a@mail.gmail.com> <20070615140618.GA29814@matrix.chaos.earth.li> <46763F4A.2090306@gmail.com> <20070618095730.GA21372@matrix.chaos.earth.li> <46767FBA.7050600@gmail.com> Message-ID: <20070618131525.GA26744@matrix.chaos.earth.li> On Mon, Jun 18, 2007 at 01:51:06PM +0100, Simon Marlow wrote: > > > >It also means that none of your internal modules can depend on any of > >your normal modules. > > Sure they can - the foo-internal package would contain all the modules > (internal + external), but the foo package would only re-expose some of > them. Sorry, yes, my brain broke. Thanks Ian From nominolo at googlemail.com Tue Jun 19 19:21:18 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Jun 19 19:16:03 2007 Subject: Testing Cabal Message-ID: Now that I built my first (bogus) package that takes advantage of configurations I tried to run the test suite again, but I'm not sure what the intended output is. What's a bit strange is that my current version drops file ".configured_cabal" in the directory where Setup.lhs is, but I can't find that file anywhere (it currently isn't removed by the clean command.) Here's what I get: $ make tests mkdir -p dist/debug ghc --make -cpp -Wall -DHAVE_UNIX_PACKAGE -DDEBUG -odir dist/debug - hidir dist/debug -idist/debug/:src:tests/HUnit-1.0/src tests/ ModuleTest.hs -o moduleTest [ 1 of 39] Compiling HUnitLang ( tests/HUnit-1.0/src/ HUnitLang.lhs, dist/debug/HUnitLang.o ) -- snip -- [ 2 of 39] Compiling HUnitBase ( tests/HUnit-1.0/src/ HUnitBase.lhs, dist/debug/HUnitBase.o ) -- etc. -- [39 of 39] Compiling Main ( tests/ModuleTest.hs, dist/ debug/Main.o ) Linking moduleTest ... rm -f Distribution/*.o Distribution/*.hi rm -f Distribution/Compat/*.o Distribution/Compat/*.hi rm -f Distribution/PreProcess/*.o Distribution/PreProcess/*.hi rm -f Distribution/Simple/*.o Distribution/Simple/*.hi rm -f Language/Haskell/*.o Language/Haskell/*.hi rm -f darcs* out.build *~ semantic.cache* x*.html rm -f library-infrastructure--darcs.tar.gz rm -rf setup *.o *.hi moduleTest dist installed-pkg-config rm -f build-stamp rm -rf dist/hugs rm -f hunit-stamp hunitInstall-stamp cd tests/HUnit-1.0 && make clean rm -f setup a.out .setup-config register.sh unregister.sh out.build rm -rf ,tmp* dist find . -name "*.o" |xargs rm -f find . -name "*.hi" |xargs rm -f find . -name "*~" | xargs rm -f cd tests/A && make clean rm -f setup a.out .setup-config register.sh unregister.sh out.build rm -rf ,tmp* dist find . -name "*.o" |xargs rm -f find . -name "*.hi" |xargs rm -f find . -name "*~" | xargs rm -f cd tests/wash2hs && make clean rm -f setup a.out .setup-config register.sh unregister.sh out.build rm -rf ,tmp* dist find . -name "*.o" |xargs rm -f find . -name "*.hi" |xargs rm -f find . -name "*~" | xargs rm -f cd doc && make clean rm -fr *~ API users-guide Cabal.pdf Cabal.dvi semantic.cache cd tests/A && make clean rm -f setup a.out .setup-config register.sh unregister.sh out.build rm -rf ,tmp* dist find . -name "*.o" |xargs rm -f find . -name "*.hi" |xargs rm -f find . -name "*~" | xargs rm -f cd tests/HUnit-1.0 && make clean rm -f setup a.out .setup-config register.sh unregister.sh out.build rm -rf ,tmp* dist find . -name "*.o" |xargs rm -f find . -name "*.hi" |xargs rm -f find . -name "*~" | xargs rm -f cd tests/A && make ghc -cpp -DCABAL_VERSION=1,1,7 --make -i../.. Setup.lhs -o setup 2>out.build cd tests/HUnit-1.0 && make ghc -cpp -DCABAL_VERSION=1,1,7 --make -i../.. Setup.lhs -o setup 2>out.build $ From duncan.coutts at worc.ox.ac.uk Wed Jun 20 00:53:30 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jun 20 00:50:11 2007 Subject: Testing Cabal In-Reply-To: References: Message-ID: <1182315211.5529.1.camel@localhost> On Wed, 2007-06-20 at 01:21 +0200, Thomas Schilling wrote: > Now that I built my first (bogus) package that takes advantage of > configurations I tried to run the test suite again, but I'm not sure > what the intended output is. What's a bit strange is that my current > version drops file ".configured_cabal" in the directory where > Setup.lhs is, but I can't find that file anywhere (it currently isn't > removed by the clean command.) I think the various . files that Cabal creates recently got moved to dist/. Duncan From ndmitchell at gmail.com Wed Jun 20 09:05:36 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jun 20 09:00:13 2007 Subject: Converting Yhc to use Cabal Message-ID: <404396ef0706200605h2ae1cdfbxe66cc3f61342adf6@mail.gmail.com> Hi, I'd like to convert Yhc to use Cabal. This presents several challenges: * We would like to depend on fps/base depending on compiler version. Configurations will allow this. * We have the library Yhc.Core in our tree which is developed in parallel with Yhc. What would be nice is to have a Yhc.Core library which we don't have to explicitly install each time. I guess having all the Yhc.Core files in both the library, and again in the program would work. * We'd ideally like multiple cabal files in one directory - for things like ycr2js, yhc, yhi etc. * Can Cabal compile C files? Can it do things like testing the size of int/long etc? * Is cabal-install ready for serious use? If so we would like to use this as our primary method of compilation. I suspect that it will not be possible to move entirely to Cabal initially - but perhaps Yhc can point out features that Cabal lacks. Thanks Neil From stefanor at cox.net Wed Jun 20 09:53:53 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Jun 20 09:48:33 2007 Subject: Converting Yhc to use Cabal In-Reply-To: <404396ef0706200605h2ae1cdfbxe66cc3f61342adf6@mail.gmail.com> References: <404396ef0706200605h2ae1cdfbxe66cc3f61342adf6@mail.gmail.com> Message-ID: <20070620135353.GA2921@localhost.localdomain> On Wed, Jun 20, 2007 at 02:05:36PM +0100, Neil Mitchell wrote: > Hi, > > I'd like to convert Yhc to use Cabal. This presents several challenges: > > * We would like to depend on fps/base depending on compiler version. > Configurations will allow this. > > * We have the library Yhc.Core in our tree which is developed in > parallel with Yhc. What would be nice is to have a Yhc.Core library > which we don't have to explicitly install each time. I guess having > all the Yhc.Core files in both the library, and again in the program > would work. > > * We'd ideally like multiple cabal files in one directory - for things > like ycr2js, yhc, yhi etc. > > * Can Cabal compile C files? Can it do things like testing the size of > int/long etc? > > * Is cabal-install ready for serious use? If so we would like to use > this as our primary method of compilation. > > I suspect that it will not be possible to move entirely to Cabal > initially - but perhaps Yhc can point out features that Cabal lacks. I beleive that the best approach would be to split the York build system into separate build systems for yhc/yhi/etc. Yhi, being a pure C program, can use a system designed for pure C, such as autotools. Yhc, being pure Haskell, would be a much better fit for Cabal than the York toolchain currently is considered as a whole. Stefan From ndmitchell at gmail.com Wed Jun 20 10:15:23 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jun 20 10:10:00 2007 Subject: Converting Yhc to use Cabal In-Reply-To: <20070620135353.GA2921@localhost.localdomain> References: <404396ef0706200605h2ae1cdfbxe66cc3f61342adf6@mail.gmail.com> <20070620135353.GA2921@localhost.localdomain> Message-ID: <404396ef0706200715t1de30f1ej759b7e800806ae6f@mail.gmail.com> Hi Stefan, > I beleive that the best approach would be to split the York build system > into separate build systems for yhc/yhi/etc. Yhi, being a pure C > program, can use a system designed for pure C, such as autotools. Which doesn't really like Windows, so isn't really an option... > Yhc, > being pure Haskell, would be a much better fit for Cabal than the York > toolchain currently is considered as a whole. The intention is to initially make Yhc compile with Cabal, and have "scons build yhc" just fork off Cabal to do the work. Gradually it would be nice to move more bits into Cabal. Thanks Neil From stefanor at cox.net Wed Jun 20 10:20:23 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Jun 20 10:15:03 2007 Subject: Converting Yhc to use Cabal In-Reply-To: <404396ef0706200715t1de30f1ej759b7e800806ae6f@mail.gmail.com> References: <404396ef0706200605h2ae1cdfbxe66cc3f61342adf6@mail.gmail.com> <20070620135353.GA2921@localhost.localdomain> <404396ef0706200715t1de30f1ej759b7e800806ae6f@mail.gmail.com> Message-ID: <20070620142023.GA3316@localhost.localdomain> On Wed, Jun 20, 2007 at 03:15:23PM +0100, Neil Mitchell wrote: > Hi Stefan, > > >I beleive that the best approach would be to split the York build system > >into separate build systems for yhc/yhi/etc. Yhi, being a pure C > >program, can use a system designed for pure C, such as autotools. > > Which doesn't really like Windows, so isn't really an option... Ah yes. Windows is a good reason to pick scons over autotools. > > Yhc, > >being pure Haskell, would be a much better fit for Cabal than the York > >toolchain currently is considered as a whole. > > The intention is to initially make Yhc compile with Cabal, and have > "scons build yhc" just fork off Cabal to do the work. Gradually it > would be nice to move more bits into Cabal. The York tools are very loosely coupled because of the documented IR. it seems kinda silly to force a common build system on them... Stefan From igloo at earth.li Wed Jun 20 11:00:32 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Jun 20 10:55:10 2007 Subject: Converting Yhc to use Cabal In-Reply-To: <404396ef0706200605h2ae1cdfbxe66cc3f61342adf6@mail.gmail.com> References: <404396ef0706200605h2ae1cdfbxe66cc3f61342adf6@mail.gmail.com> Message-ID: <20070620150032.GA8453@matrix.chaos.earth.li> On Wed, Jun 20, 2007 at 02:05:36PM +0100, Neil Mitchell wrote: > > * We would like to depend on fps/base depending on compiler version. > Configurations will allow this. Although if you don't have base+bytestring then you'll have to compile a Cabal that supports configurations yourself. For older compilers you can just make an empty bytestring package, of course. > * We'd ideally like multiple cabal files in one directory - for things > like ycr2js, yhc, yhi etc. Why do you want that? Based on http://darcs.haskell.org/yhc/src/SConscript it looks like you pretty much have a directory per project, so why not put the .cabal files in those directories? You can then write a Setup.hs for the root such that, for example, "Setup build" builds all of the child cabal packages and "Setup build yhi" just builds yhi, for example. This root Setup.hs wouldn't actually use any of the Cabal API yet, although we might want to support meta-package .cabal files in the future, for exactly this sort of use. > * Can Cabal compile C files? Yes. > Can it do things like testing the size of > int/long etc? No. Thanks Ian From bos at serpentine.com Wed Jun 20 11:58:23 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed Jun 20 11:55:01 2007 Subject: Converting Yhc to use Cabal In-Reply-To: <20070620142023.GA3316@localhost.localdomain> References: <404396ef0706200605h2ae1cdfbxe66cc3f61342adf6@mail.gmail.com> <20070620135353.GA2921@localhost.localdomain> <404396ef0706200715t1de30f1ej759b7e800806ae6f@mail.gmail.com> <20070620142023.GA3316@localhost.localdomain> Message-ID: <46794E9F.1060806@serpentine.com> Stefan O'Rear wrote: > On Wed, Jun 20, 2007 at 03:15:23PM +0100, Neil Mitchell wrote: >> Hi Stefan, >> >>> I beleive that the best approach would be to split the York build system >>> into separate build systems for yhc/yhi/etc. Yhi, being a pure C >>> program, can use a system designed for pure C, such as autotools. >> Which doesn't really like Windows, so isn't really an option... > > Ah yes. Windows is a good reason to pick scons over autotools. There's also cmake, which might be a better option. If you're not already using scons, I wouldn't recommend it, based on painful experience with its inflexibility. References: <404396ef0706200605h2ae1cdfbxe66cc3f61342adf6@mail.gmail.com> <20070620150032.GA8453@matrix.chaos.earth.li> Message-ID: <467A3FE5.4040208@gmail.com> Ian Lynagh wrote: >> Can it do things like testing the size of >> int/long etc? > > No. But of course the advantage of Setup.hs is that you can write code to do anything you like in there, including tests for the size of int/long. Cheers, Simon From nominolo at googlemail.com Sat Jun 23 17:58:43 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Sat Jun 23 23:31:47 2007 Subject: darcs patch: Added documentation. (and 25 more) Message-ID: <467d9793.0735640a.7650.ffffedab@mx.google.com> Mon May 28 23:12:21 CEST 2007 Thomas Schilling * Added documentation. Tue May 29 22:59:58 CEST 2007 Thomas Schilling * Extended low-level parsing routines to also allow labelled blocks and if-blocks. Tue May 29 23:03:44 CEST 2007 Thomas Schilling * Added Configuration parsing and simplification. Wed Jun 13 19:21:14 CEST 2007 Thomas Schilling * Abstracted variables out of conditions. Generalized simplification function to accept an arbitrary partial assignment of these variables. Wed Jun 13 19:22:30 CEST 2007 Thomas Schilling * fixed typo Wed Jun 13 19:23:09 CEST 2007 Thomas Schilling * added docs Wed Jun 13 19:24:16 CEST 2007 Thomas Schilling * add flag as a section Wed Jun 13 19:35:48 CEST 2007 Thomas Schilling * add line numbers to all field times Wed Jun 13 20:43:32 CEST 2007 Thomas Schilling * Prototypical configurations Thu Jun 14 14:50:31 CEST 2007 Thomas Schilling * Pretty printing of conditions and CondTrees. Non-dependency information of CondTrees is now a modifier. Move CondTree resolution functionality. Mon Jun 18 21:53:29 CEST 2007 Thomas Schilling * Compatibility parsing and working configurations. Mon Jun 18 21:54:49 CEST 2007 Thomas Schilling * Add commandline support for specifying defaults for flags. Mon Jun 18 21:57:10 CEST 2007 Thomas Schilling * Add helpers for reading and writing the file to hold a configured cabal-file. Sat Jun 23 22:04:53 CEST 2007 Thomas Schilling * Fixed warnings, added documentation, and changed os and arch names to simple strings. Sat Jun 23 22:05:22 CEST 2007 Thomas Schilling * Fixed warning Sat Jun 23 22:07:01 CEST 2007 Thomas Schilling * Make explicit that reading package descriptions isn't supported here, ATM. Sat Jun 23 22:11:35 CEST 2007 Thomas Schilling * Fix warnings, add documentation and changes in response to some interface changes. Sat Jun 23 22:12:54 CEST 2007 Thomas Schilling * Fix warnings. Sat Jun 23 22:14:55 CEST 2007 Thomas Schilling * Downcase flagnames. Re-add config flags (were removed due to update). Sat Jun 23 22:15:46 CEST 2007 Thomas Schilling * Adjust to new package reading interface. Sat Jun 23 22:17:23 CEST 2007 Thomas Schilling * Fix warnings. Sat Jun 23 22:20:17 CEST 2007 Thomas Schilling * Add proper handling of configurations to configure command. Sat Jun 23 22:23:33 CEST 2007 Thomas Schilling * Fix typo. Sat Jun 23 22:31:21 CEST 2007 Thomas Schilling * Disable (comment out) tests for now. Break due to changed interface. Sat Jun 23 22:39:39 CEST 2007 Thomas Schilling * Properly fix tests. Sat Jun 23 22:47:06 CEST 2007 Thomas Schilling * Re-add configurations module to .cabal file. (Got removed on update.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 158911 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070623/e9943bf2/attachment-0001.bin From nominolo at googlemail.com Sun Jun 24 06:41:32 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Jun 24 06:36:00 2007 Subject: RFC: Cabal-Configurations patch(es) Message-ID: <56F876BB-5EE8-4578-8A48-5F412E774031@googlemail.com> Hi, you just received a longish patch bundle, that together implement Cabal configurations. I realized too late that there's a way to combine this mail with the actual patch, so consider this an addendum. The implementation can read all old Cabal-files (and should do the same), but unfortunately, I had to change the interface of the confHook function, which I assume will break some setup files. The documentation states, that you shouldn't depend on that interface, but then again do people have to use them if they have special requirements. The most important change is, that Cabal files are now parsed to 'PreparedPackageDescription' which requires a run of 'finalizePackageDescription' to get to the actual 'PackageDescription'. This resolving process is potentially very slow (exponential in the number of flags), especially if there is no possible flag assignment. I plan to correct this by adding some minimum SAT solving capabilities, which will however still be exponential in the worst case. For now, the current implementation should be sufficient, though. My testing is far from exhaustive, as I haven't yet found a good way of setting up a suitable test environment without endangering to break my current setup. I am setting up a ghc-HEAD installation, but there is currently a build error stopping me from it. Incidentally, Cabal itself now needs configurations to build with ghc-head as well as ghc-6.6.1. That said, I'd like to ask you to review the patches and possibly also test it on your projects. A preliminary HOWTO is at: http://hackage.haskell.org/trac/hackage/wiki/CabalConfigurations Thanks, / Thomas From nominolo at googlemail.com Sun Jun 24 13:05:43 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Jun 24 13:00:11 2007 Subject: RFC: Cabal-Configurations patch(es) In-Reply-To: <56F876BB-5EE8-4578-8A48-5F412E774031@googlemail.com> References: <56F876BB-5EE8-4578-8A48-5F412E774031@googlemail.com> Message-ID: <07B5C546-EA8B-4425-B2A0-37A6E2238A66@googlemail.com> You can also browse the source at: http://code.haskell.org/~nominolo/src/cabal+configs/ / Thomas On 24 jun 2007, at 12.41, Thomas Schilling wrote: > Hi, > > you just received a longish patch bundle, that together implement > Cabal configurations. I realized too late that there's a way to > combine this mail with the actual patch, so consider this an addendum. > > The implementation can read all old Cabal-files (and should do the > same), but unfortunately, I had to change the interface of the > confHook function, which I assume will break some setup files. The > documentation states, that you shouldn't depend on that interface, > but then again do people have to use them if they have special > requirements. > > The most important change is, that Cabal files are now parsed to > 'PreparedPackageDescription' which requires a run of > 'finalizePackageDescription' to get to the actual > 'PackageDescription'. This resolving process is potentially very > slow (exponential in the number of flags), especially if there is > no possible flag assignment. I plan to correct this by adding some > minimum SAT solving capabilities, which will however still be > exponential in the worst case. For now, the current implementation > should be sufficient, though. > > My testing is far from exhaustive, as I haven't yet found a good > way of setting up a suitable test environment without endangering > to break my current setup. I am setting up a ghc-HEAD > installation, but there is currently a build error stopping me from > it. Incidentally, Cabal itself now needs configurations to build > with ghc-head as well as ghc-6.6.1. > > > That said, I'd like to ask you to review the patches and possibly > also test it on your projects. A preliminary HOWTO is at: > > http://hackage.haskell.org/trac/hackage/wiki/CabalConfigurations > > Thanks, > > / Thomas > From ndmitchell at gmail.com Wed Jun 27 11:18:25 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jun 27 11:12:39 2007 Subject: Broken Cabal on Windows Message-ID: <404396ef0706270818h62f9299fo1074daacc326c3de@mail.gmail.com> Hi I've got Windows, GHC 6.6.1 and I just tried to upgrade Cabal. Now Cabal is totally broken on my system. >From the Cabal directory: $ darcs pull $ runhaskell Setup configure $ runhaskell Setup build $ runhaskell Setup install All completed with a nice pile of warnings, but no errors. Then from any other Cabal package directory: D:\sources\temp\catch-0.1>runhaskell Setup configure : C:\Program Files\Haskell\Cabal-1.1.7\ghc-6.6.1/HSCabal-1.1.7.o: unknown symbol ` _Cabalzm1zi1zi7_DistributionziCompatziFilePath_slash_closure' ghc.exe: unable to load package `Cabal-1.1.7' Obviously this breaks Cabal entirely on my system. Thanks Neil From ndmitchell at gmail.com Wed Jun 27 11:32:36 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Jun 27 11:26:50 2007 Subject: Broken Cabal on Windows In-Reply-To: <404396ef0706270818h62f9299fo1074daacc326c3de@mail.gmail.com> References: <404396ef0706270818h62f9299fo1074daacc326c3de@mail.gmail.com> Message-ID: <404396ef0706270832m54d90255h81ca1dc93e5e49f9@mail.gmail.com> Hi Turns out a complete delete of the tree and a fresh checkout works fine - seems like a niggle relating to the removal of Compat.FilePath. All fixed now. Thanks Neil On 6/27/07, Neil Mitchell wrote: > Hi > > I've got Windows, GHC 6.6.1 and I just tried to upgrade Cabal. Now > Cabal is totally broken on my system. > > From the Cabal directory: > $ darcs pull > $ runhaskell Setup configure > $ runhaskell Setup build > $ runhaskell Setup install > > All completed with a nice pile of warnings, but no errors. > > Then from any other Cabal package directory: > D:\sources\temp\catch-0.1>runhaskell Setup configure > : > C:\Program Files\Haskell\Cabal-1.1.7\ghc-6.6.1/HSCabal-1.1.7.o: unknown symbol ` > _Cabalzm1zi1zi7_DistributionziCompatziFilePath_slash_closure' > ghc.exe: unable to load package `Cabal-1.1.7' > > Obviously this breaks Cabal entirely on my system. > > Thanks > > Neil > From nominolo at googlemail.com Wed Jun 27 21:12:03 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Wed Jun 27 21:06:31 2007 Subject: Cabal Configurations - Beta-Testers Wanted Message-ID: Hello Cafe! Cabal configurations are an often-requested new feature of Haskell's packaging system Cabal. As part of my Google Summer of Code project I implemented it with the feature set of the latest proposal[1]. I would now like people to try it out and give some feedback if it solves their problems, if there are bugs with the current implementation, or if it breaks any install scripts. So, if you have written a package and think your package could profit from Cabal configurations, please adjust your package description and try to build it on as many systems as possible and report any problems (or successes). Following are some instructions to get started. Thanks, / Thomas INSTALLING [Note: The following build instructions are for a recent GHC. If you have another Haskell compiler/interpreter you'll probably have to adjust these steps a bit. Please report any problems you encounter.] You should be able to get Cabal with configurations via: $ darcs get --partial http://code.haskell.org/~nominolo/src/cabal +configs/ Before installing you might want to hide the current cabal package using (tt shouldn't be necessary, though) via $ ghc-pkg hide Cabal or $ sudo ghc-pkg hide Cabal depending on where Cabal is installed. Installing the new Cabal should be as simple as: $ cd cabal+configs $ make install user=y PREF=~/sw This will build Cabal with version 1.1.7, register it in the current user's package database, and install it to the "sw" directory of the current user home directory. Adjust the parameters to your needs. To remove use: $ make remove user=y PREF=~/sw NEW FEATURES The new constructs didn't integrate well with the conventional syntax, so I changed it to a C-style block-style syntax. (This is consistent with Haskell's use of { .. } in do-blocks; adding or replacing this with an indentation-based approach is thinkable and might actually integrate better with the rest of Cabal file syntax. So yell if you want it--but no bike sheds please! ;) The new syntax structures cabal files like this: global properties optional flags descriptions Library { library build properties and conditionals } Executable name { executable build properties and conditionals } For an example, see below. Inside the Library and executable sections you can now use conditionals with the syntax: body: cabal_stanza "\n" body | "if" conditional "{" body "}" [ "else" "{" body "}" ] body | conditional: "os(" string ")" | "arch(" string ")" | "flag(" flagname ")" | "True" | "False" | "!" conditional | conditional "||" conditional | conditional "&&" conditional | "(" conditional ")" Note that you cannot test for dependencies directly. The user either specifies certain features she wants by switching flags on or off during the configure step or Cabal picks a suitable flag assignment for you, depending on which dependencies are available. Unless specified otherwise, flag assignments default to True. ATM, the only field specifying dependencies is "build-depends". Options specified inside a conditional are (mostly) added to the values specified outside. E.g. GHC-Options: -Wall if flag(debug) { GHC-Options: -DDEBUG } when built with flag "debug" set to True will be built with GHC-Options: -Wall -DDEBUG For a more detailed description see[1]. The following example .cabal- file should demonstrate the features (it is also available and updated at[2]): Name: Test1 Version: 0.0.1 Cabal-Version: >= 1.1.7 License: BSD3 -- License-File: LICENSE Author: Thomas Schilling Maintainer: Thomas Schilling --Homepage: http://www.example.com/ Synopsis: Test package to test configurations Description: See synopsis. . Really. Category: Useless Flag Debug { Description: Enable debug support Default: False } Flag NoBuild { Description: Inhibit building this package. -- defaults to True } Library { Build-Depends: base Exposed-Modules: Testing.Test1 Extensions: CPP -- flag names are case insensitive if flag(debuG) { CC-Options: "-DDEBUG" GHC-Options: -DDEBUG } if flag(NoBuild) { Build-Depends: nonexistentpackage } } Executable test1e { Main-is: T1.hs Other-modules: Testing.Test1 if flag(debug) { CC-Options: "-DDEBUG" GHC-Options: -DDEBUG } } When configuring it with the usual command line, you now get an additional line, showing which flags were chosen: $ ./Setup.lhs configure configure: Reading installed packages... Configuring Test1-0.0.1... configure: Flags chosen: nobuild=False, debug=False Setup.lhs: Warning: No license-file field. configure: Dependency base-any: using base-2.1.1 [...] Note that, even though the default for the "nobuild" flag was True, the required dependencies weren't present, so it was forced to False. If you want to force flags to certain values you can do so by giving the --flags or -f flag to configure. Listing the (case-insensitive) name forces it to True, putting a "-" in front of the name forces it to False. For example: $ ./Setup.lhs configure -fdebug configure: Reading installed packages... Configuring Test1-0.0.1... configure: Flags chosen: nobuild=False, debug=True Setup.lhs: Warning: No license-file field. [...] or $ ./Setup.lhs configure --flags="-debug nobuild" configure: Reading installed packages... Configuring Test1-0.0.1... Setup.lhs: At least the following dependencies are missing: nonexistentpackage -any $ Note that if you want to change the configuration of a package, you have to ./Setup.lhs clean first, to make sure everything gets recompiled. Good Luck! [1] http://www.mail-archive.com/cabal-devel@haskell.org/msg00282.html [2] http://hackage.haskell.org/trac/hackage/wiki/CabalConfigurations From nominolo at googlemail.com Thu Jun 28 07:39:50 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Jun 28 07:34:07 2007 Subject: [Haskell-cafe] Cabal Configurations - Beta-Testers Wanted In-Reply-To: References: Message-ID: Hi Pepe, I partially fixed it. A full fix would require a feature that is not yet implemented. I'll take a look at it later today. The problem was, that shim has no library section, but my compatibility translator created an incomplete one, just to carry the dependencies. The right solution would be to add them to each executable, but there they won't be check yet for them, yet. So, your Cabal file is now internally translated to: Name: shim Version: 0.1 License: BSD3 License-file: LICENSE Copyright: (c) 2006 Benedikt Schmidt Maintainer: Benedikt Schmidt Library { -- library section is only there to contain the dependencies -- It is therefore marked as not buildable Buildable: False Build-Depends: unix, ghc, haskell98, base, parsec, network, Cabal<1.1.7, mtl, filepath } Executable shim { Main-is: Main.hs Ghc-Options: -O0 } Executable shim-udproxy { Main-is: Shim/Udproxy.hs Ghc-Options: -O0 -main-is Shim.Udproxy.main } Please, update cabal+configs. > > > configure: Reading installed packages... > > Configuring shim-0.1... > > Setup.lhs: Error: Non-empty library, but empty exposed modules > list. Cabal may not build this library correctly > > > If this is a bug, let me know as soon as it's fixed. > I want to use the os() predicate in the shim descriptor, is that > already working? This should work: Name: shim Version: 0.1 License: BSD3 License-file: LICENSE Copyright: (c) 2006 Benedikt Schmidt Maintainer: Benedikt Schmidt Library { Buildable: False if os(mingw32) { Build-depends: ghc, haskell98, base, parsec, network, Cabal<1.1.7, mtl, filepath } else { Build-Depends: unix, ghc, haskell98, base, parsec, network, Cabal<1.1.7, mtl, filepath } } Executable shim { Main-is: Main.hs Ghc-Options: -O0 } Executable shim-udproxy { Main-is: Shim/Udproxy.hs Ghc-Options: -O0 -main-is Shim.Udproxy.main } BTW, the os() test should test for the value returned by System.Info.os . / Thomas From clemens at endorphin.org Thu Jun 28 08:03:44 2007 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Thu Jun 28 15:37:39 2007 Subject: darcs patch: Add --enable-shared as configure argument, and ghc-sha... Message-ID: <20070628120358.112FEE80CD@hwi.endorphin.org> Thu Jun 28 13:45:35 CEST 2007 Clemens Fruhwirth * Add --enable-shared as configure argument, and ghc-shared-options as .cabal field -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 41212 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070628/97dd02de/attachment-0001.bin From clemens at endorphin.org Fri Jun 29 07:02:27 2007 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Fri Jun 29 09:00:50 2007 Subject: darcs patch: Add mkSharedLibName for generating the mangled library... Message-ID: <20070629110219.E3A4FE8056@hwi.endorphin.org> Thu Jun 28 13:48:55 CEST 2007 Clemens Fruhwirth * Add mkSharedLibName for generating the mangled library name -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 40722 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070629/326c6ea9/attachment-0001.bin From clemens at endorphin.org Fri Jun 29 07:02:41 2007 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Fri Jun 29 09:00:51 2007 Subject: darcs patch: For shared libs compile .hs and .c files with -fPIC, a... Message-ID: <20070629110234.7B6D7E8056@hwi.endorphin.org> Thu Jun 28 13:49:51 CEST 2007 Clemens Fruhwirth * For shared libs compile .hs and .c files with -fPIC, and link with new ghc -shared option. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 43645 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070629/87399281/attachment-0001.bin From clemens at endorphin.org Fri Jun 29 07:03:02 2007 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Fri Jun 29 09:00:52 2007 Subject: darcs patch: Add dynamic way for building via GHC Makefiles Message-ID: <20070629110255.839DDE8056@hwi.endorphin.org> Fri Jun 29 12:58:40 CEST 2007 Clemens Fruhwirth * Add dynamic way for building via GHC Makefiles -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 40813 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070629/e17c922f/attachment-0001.bin From clemens at endorphin.org Fri Jun 29 07:03:11 2007 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Fri Jun 29 09:00:52 2007 Subject: darcs patch: Regenerate GHCMakefile.hs Message-ID: <20070629110304.950B0E831C@hwi.endorphin.org> Fri Jun 29 12:58:56 CEST 2007 Clemens Fruhwirth * Regenerate GHCMakefile.hs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 49579 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070629/ed8ac39b/attachment-0001.bin From igloo at earth.li Fri Jun 29 09:20:48 2007 From: igloo at earth.li (Ian Lynagh) Date: Fri Jun 29 09:21:27 2007 Subject: RFC: Cabal-Configurations patch(es) In-Reply-To: <56F876BB-5EE8-4578-8A48-5F412E774031@googlemail.com> References: <56F876BB-5EE8-4578-8A48-5F412E774031@googlemail.com> Message-ID: <20070629132048.GA9879@matrix.chaos.earth.li> Hi Thomas, On Sun, Jun 24, 2007 at 12:41:32PM +0200, Thomas Schilling wrote: > > you just received a longish patch bundle, that together implement > Cabal configurations. Great! Things mostly seem to work in the HEAD. I'm attaching a couple of patches that I needed. I've also moved some of base/Setup.hs into base/base.cabal, although I haven't checked that it works yet. One thing I found is that I needed an IsGHC flag; should there be an impl(GHC) built-in? I guess further down this road is testing the /version/ of the implementation as well, and perhaps even the tags. Also, I'm not sure how to patch up libraries/installPackage.hs. It used to do pdFile <- defaultPackageDesc verbosity pd <- readPackageDescription verbosity pdFile lbi <- getPersistBuildConfig so I think I now want to do pdFile <- defaultPackageDesc verbosity ppd <- readPackageDescription verbosity pdFile lbi <- getPersistBuildConfig pd <- finalizePackageDescription lbi ppd except finalizePackageDescription doesn't work like that. What's the best way to do this? Thanks Ian -------------- next part -------------- New patches: [Cabal can't have a Cabal-Version header; it breaks bootstrapping Ian Lynagh **20070629131043] { hunk ./Cabal.cabal 3 -Cabal-Version: >= 1.1.7 } [Handle ConfigureOption's in parseConfigureArgs Ian Lynagh **20070629131105] { hunk ./Distribution/Setup.hs 633 + updateCfg t (ConfigureOption o) = t { configConfigureArgs = o : configConfigureArgs t } } Context: [Partial bugfix to allow traditional .cabal files without a library but Thomas Schilling **20070628112301 global build dependencies. The correct solution is to add global dependencies to each executable and implement dependency resolution for executables. The current workaround is to add the dependencies to the library, but disable building of the library. ] [Take advantage of configurations to build Cabal itself and fix bootstrapping problem. Thomas Schilling **20070628081438] [Re-add configurations module to .cabal file. (Got removed on update.) Thomas Schilling **20070623204706] [Properly fix tests. Thomas Schilling **20070623203939] [Disable (comment out) tests for now. Break due to changed interface. Thomas Schilling **20070623203121] [Fix typo. Thomas Schilling **20070623202333] [Add proper handling of configurations to configure command. Thomas Schilling **20070623202017] [Fix warnings. Thomas Schilling **20070623201723] [Adjust to new package reading interface. Thomas Schilling **20070623201546] [Downcase flagnames. Re-add config flags (were removed due to update). Thomas Schilling **20070623201455] [Fix warnings. Thomas Schilling **20070623201254] [Fix warnings, add documentation and changes in response to some Thomas Schilling **20070623201135 interface changes. ] [Make explicit that reading package descriptions isn't supported here, ATM. Thomas Schilling **20070623200701] [Fixed warning Thomas Schilling **20070623200522] [Fixed warnings, added documentation, and changed os and arch names to Thomas Schilling **20070623200453 simple strings. ] [Add helpers for reading and writing the file to hold a configured cabal-file. Thomas Schilling **20070618195710] [Add commandline support for specifying defaults for flags. Thomas Schilling **20070618195449] [Compatibility parsing and working configurations. Thomas Schilling **20070618195329] [Pretty printing of conditions and CondTrees. Non-dependency Thomas Schilling **20070614125031 information of CondTrees is now a modifier. Move CondTree resolution functionality. ] [Prototypical configurations Thomas Schilling **20070613184332] [add line numbers to all field times Thomas Schilling **20070613173548] [add flag as a section Thomas Schilling **20070613172416] [added docs Thomas Schilling **20070613172309] [fixed typo Thomas Schilling **20070613172230] [Abstracted variables out of conditions. Generalized simplification Thomas Schilling **20070613172114 function to accept an arbitrary partial assignment of these variables. ] [Added Configuration parsing and simplification. Thomas Schilling **20070529210344] [Extended low-level parsing routines to also allow labelled blocks and if-blocks. Thomas Schilling **20070529205958] [Added documentation. Thomas Schilling **20070528211221] [update output Ross Paterson **20070620152404] [break up the long string literal Ross Paterson **20070620152103 This makes the output work with implementations (like Hugs) that impose a limit on the size of string literals. ] [update Simon Marlow **20070620091950] [include Makefile.local if it exists; allows local customization Simon Marlow **20070620091946] [clean up .hi-boot and .o-boot Simon Marlow **20070620091843] [add a "DO NOT EDIT" notice to the top of Cabal-generated Makefiles Simon Marlow **20070620091759] [Fix warning Ian Lynagh **20070615183346] [report non-option arguments as errors (fixes #90 and #113) Ross Paterson **20070607082326 Formerly, non-option arguments to all commands were silently ignored. Now setup halts with an error message in this case. ] [Fix error message regression Simon Marlow **20070606142650 Passing a non-existent program for --with-hc-pkg used to say this: $ ./Setup configure --with-hc-pkg=foo Configuring QuickCheck-2.0... /bin/sh: foo: command not found Setup: executing external program failed: "foo" --global list >tmp23634 Now it is rather less useful: $ ./setup configure --with-hc-pkg=foo configure: Reading installed packages... zsh: 23596 exit 127 ./setup configure --with-hc-pkg=foo This patch restores the old behaviour, slightly improved: $ ./Setup --with-hc-pkg=foo configure configure: Reading installed packages... Setup: executing external program failed (exit 127) : foo --global list ] [don't pass unrecognized arguments to ./configure Ross Paterson **20070605231500 They are now reported as errors. To pass them to configure, use the new --configure-option flag. Non-option arguments are still ignored (#90 and #113), as with all of the other commands. ] [add --cpphs-options Ross Paterson *-20070115141053] [add --cpphs-options Ross Paterson **20070115141053] [implement --configure-option and --ghc-option (#139) Ross Paterson **20070604114851 Added options used for building in the GHC tree: setup configure --configure-option=STR setup build --ghc-option=STR setup makefile --ghc-option=STR These were formerly scattered across Setup.hs files. ] [warning police on SetupWrapper Ross Paterson **20070603104827] [trim imports Ross Paterson **20070603104802] [include preprocessed modules in setup haddock (fixes #138) Ross Paterson **20070602195508] [move dotfiles into dist Ross Paterson **20070602175348 .setup-config -> dist/setup-config .installed-pkg-config -> dist/installed-pkg-config .inplace-pkg-config -> dist/inplace-pkg-config ] [mark mkGHCMakefile.sh and GHCMakefile.in as source files Ross Paterson **20070601155538 so that they'll be included in source distributions of this package. ] [cope with ghc-pkg returning multiple values for a field Ross Paterson **20070601155450] [Add and use createDirectoryIfMissingVerbose Ian Lynagh **20070602002507 rather than createDirectoryIfMissing ] [Overwrite .installed-pkg-config if it exists when registering Ian Lynagh **20070530150838] [Close the handle of temporary files before removing them Ian Lynagh **20070529192852 The removal fails on Windows if we don't, giving unhelpful errors like Setup.exe: .\tmp3660: removeFile: permission denied (Permission denied) ] [add nhc98-options: field to .cabal file Malcolm.Wallace@cs.york.ac.uk**20070528122833] [Fix warnings in Paths_* autogenerated module Ian Lynagh **20070527220538] [Fix quoting when doing gen-script of ' in descriptions Ian Lynagh **20070526154747 It used to turn into '', which just disappears. Now it turns into '\''. ] [Add Distribution.Simple.GHCMakefile to Exposed-Modules Ian Lynagh **20070526153905] [old nhc98 Makefiles now obsolete Malcolm.Wallace@cs.york.ac.uk**20070525133004] [fix compilation with GHC 6.2.x Simon Marlow **20070523083703] [avoid overflowing the argument limit when building a split-objs lib Simon Marlow **20070524134817] [Improvements for 'setup makefile' Simon Marlow **20070524132736 - now the makefile can build the library too; so 'setup build' isn't required (unless there are post-build steps). This will be necessary for bootstrapping GHC from .hc files, where we'll be using Makefiles generated by 'setup makefile' to build the libraries. - the Makefile tempate is in a text file, processed into a .hs file by a small script (mkGHCMakefile.sh). This is run by hand for now, and I've included the generated module, so there shouldn't be any problems with building Cabal. - some cleanup and refactoring in Distribution.Simple.GHC ] [fix cut&pasto Simon Marlow **20070520185605] [generalise type of xargs Simon Marlow **20070520185556] [Remove package.conf.in and GHC bits of Makefile (used in the old build system) Ian Lynagh **20070524142725] [Pass rawSystemStdout verbosity, not verbose Ian Lynagh **20070523212145] [We now depend on process Ian Lynagh **20070523181444] [We now depend on pretty, directory and old-time Ian Lynagh **20070522133304] [now needs -package filepath Malcolm.Wallace@cs.york.ac.uk**20070522085446] [Dumping Distribution.Compat.FilePath in favor of System.FilePath Pepe Iborra **20070521125919 sorry folks, Compat.FilePath is gone ] [Get right the verbosity correspondence for GHC Pepe Iborra **20070521124306 GHC has more verbosity levels than Distribution.Verbosity, this patch gives a more accurate correspondence ] [portability fix Ross Paterson **20070521113908] [custom show'ers for Verbosity Pepe Iborra **20070520233520] [Export simpleUserHooks Ian Lynagh **20070518152026] [FIX BUILD with GHC 6.2.x Simon Marlow **20070516103919] [cope with pre-requisite packages with empty haddock fields (like rts) Ross Paterson **20070515150935] [Small tidyup Ian Lynagh **20070515151409] [rejig location of package interfaces for haddock Ross Paterson **20070515110833 Formerly, setup haddock invoked haddock with a --use-package option for each prerequisite package, causing haddock to invoke ghc-pkg to get the haddock-interfaces and haddock-html fields for each package. The former is accurate, but the latter is not what you want if your documentation is to be placed on the web. Now setup haddock invokes ghc-pkg itself, but if the --html-location option is given, its argument is expanded for each package and used instead of the haddock-html field. The results are then assembed as --read-interface options for haddock. For example, setup haddock '--html-location=http://hackage.haskell.org/packages/archive/$pkg/latest/doc/html' generates HTML documentation with hyperlinks pointing at the pages on HackageDB. ] [Put some comments in about what the verbosity stuff means Ian Lynagh **20070515125013] [Fix warnings Ian Lynagh **20070514173011] [Fix warnings Ian Lynagh **20070514171124] [Fix a warning Ian Lynagh **20070514170157] [Fix warnings Ian Lynagh **20070514165951] [Make a proper verbosity type, rather than using Int values Ian Lynagh **20070514165514 Hopefully this will make it easier to get better verbosity consistency. We could, by changing only Distribution.Verbosity, use "type Verbosity = Int" for now to give users of the library a chance to catch up, but the upcoming Cabal release seems like a good opportunity to cram in as much of the interface-changing stuff that we want to do as we can. I think the added benefit of a slow switch would be very low indeed. ] [Compile with -Wall Ian Lynagh **20070514161917] [separate build and output directory for Hugs build Ross Paterson **20070513001502 Hugs requires a separate directory for the output files from the directory containing the preprocessed files. The --scratchdir option now sets the former (and thus has an effect only for Hugs). This repairs the Hugs build. ] [non-GHC version of rawSystemStdout Ross Paterson **20070513001017] [remove copy of cabal-install library Ross Paterson **20070501160347] [Use Control.Exception even for nhc98 now. Malcolm.Wallace@cs.york.ac.uk**20070504144146] [remove cabal-install and cabal-setup from Makefile Duncan Coutts **20070503220644 These are no longer in the tree, they have their own repos now. ] [Fix more verbosity settings of messages Duncan Coutts **20070503213124] [Fix import of IO.try Duncan Coutts **20070503205024 Hopefully System.IO.Error exists for nhc98 too. ] [For nhc98, restore 'systemGetStdout' under the name 'rawSystemStdout' :-) Malcolm.Wallace@cs.york.ac.uk**20070503145457 This should now be equivalent in functionality to what was previously removed. ] [Hack around non-portable System.Process stuff for nhc98. Malcolm.Wallace@cs.york.ac.uk**20070503142544 This is enough to permit Cabal to compile again, but it certainly won't run. ] [Fix a couple verbosity settings Duncan Coutts **20070502211900 Showing what files are copied should only be shown at verbosity level 2 and above. The default verbosity level is 1. Similarly, creating the hidden package registration file should not be shown at the default verbosity level. ] [fix installIncludeFiles again. Bertram Felgenhauer **20070502182917 the include file directory must be created for ghc, otherwise package registration will fail. sigh. ] [nhc98 does not have Control.Exception Malcolm.Wallace@cs.york.ac.uk**20070502122017] [fix Haddock syntax error Simon Marlow **20070502093700] [Add test case for platform dependent and independent generated sources Duncan Coutts **20070501142716 The c2hs .hs files should go in dist/build while the happy .hs source should remain in the src dir and end up in the sdist tarball. ] [fix installIncludeFiles thinko Bertram Felgenhauer **20070501131608 due to the newly added guard, the "Can't happen" is no longer true. ] [Do not delete platform independent pre-processed sources during sdist Duncan Coutts **20070501142419 Since only platform independent pre-processed sources are now left in the src dirs we don't have to delete any pre-processed sources and can just inlcude them all into the src tarball. Ideally we'd track this slightly better in future, it's not nice to be keeping any generates sources in the src dirs, they should be considered read-only. ] [Leave platform independent pre-processed sources in the src dir Duncan Coutts **20070501142323 Only put platform dependent ones into dist/build ] [Record if pre-processors are platform independent Duncan Coutts **20070501142147 PreProcessor is now a record with a couple fields. Quite a few knock-on changes due to changing this data type. ] [call c2hs using the more detailed info Duncan Coutts **20070422102617 we use --output-dir=dist/base and --output=.hs This actually depends on a patch in c2hs to make it treat --output-dir in the way we want. That patch will be forthcomming soonish. But the point is: c2hs --output-dir=dist/base --output=Foo/Bar.hs src/Foo/Bar.chs will generate dist/base/Foo/Bar.hs and also dist/base/Foo/Bar.h but inside the .hs file it'll reference Foo/Bar.h so when we compile the .hs file we have to -Idist/base Clear as mud? ] [Generalise PreProcessors to take more detailed args Duncan Coutts **20070422100558 Most pre-processors just need the full source file and target file names. More complicated ones where the generated files have to embed links to each other need more information. For example c2hs generates .hs file that reference generated .h files. These links should be relative to the dist/build dir and not to the top of the source tree, since we do not want to add -I. to the includes search path. We only want to use -Idist/build, hence the embeded links must be relative to that. Therefor c2hs needs to know the base output directory as well as the name of the file relative to that. So we add a new type PreProcessorFull that has this extra info and a function simplePP :: :: PreProcessor -> PreProcessorFull for the common case of most existing pre-processors that do not need this extra info. This patch doesn't actually change the c2hs stuff, that comes next. ] [Put pre-processed source into the dist/build dir rather than src dirs Duncan Coutts **20070422095631 This is generally just a nicer thing to do, we should probably aim to not write any files into the source tree at all. The main change is in the preprocessModule function. It now takes an extra arg which is the destination directory. For now I'm passing the buildDir, but we could consider putting pre-processed files into a separate fir from where the .o and .hi files end up. To work out the correct destination file we need to know not only the source file but which of the search dirs it was found in, since the relative file name will be the name of the source file relative to the search dir it was found in, not the name relative to the top of the source tree. This is so that we will be able to find the pre-processed .hs file just by adding dist/build to the sources search path when we compile (eg with -i for ghc). This almost certainly breaks the sdist thing where pre-processed files get included into the tarball. So that'll need looking at. ] [update documentation for install-headers: field Bertram Felgenhauer **20070420131524] [install headers for all compilers Bertram Felgenhauer **20070420123527 This patch moves the installation of header files from Distribution.Simple.GHC to Distribution.Simple.Install. This is required for the header files to be usable for preprocessing Haskell code in other packages. ] [don't automatically include install-include: headers into compilations via C Bertram Felgenhauer **20070420123418 This way it's possible to install header files that are meant for preprocessing Haskell code, or header files that are meant to be indirectly included by others. ] [Don't overwrite existing makefiles Duncan Coutts **20070430203552 Patch contributed by Bryan O'Sullivan ] [Fix openTempFile so it works on windows with ghc at least Duncan Coutts **20070430185744 It's still a hack. The right solution is to proerly implement openTempFile in base for all Haskell impls, not just GHC. ] [Use rawSystem not system for capturing output of commands Duncan Coutts **20070430184046 For example we were using a wrapper around 'system' to find the haddock version. This invokes the system command interpreter and passes the command to run as an argument. If the command has spaces in it and is not properly escaped then everything goes wrong. This happens for example on windows when haddock and other programs are kept under "Program Files". So the right thing to do is never to use system, but always rawSystem since then there are no escaping issues. This patch replaces a couple function systemCaptureStdout and systemGetStdout with rawSystemStdout which now lives in Distribution.Simple.Utils. This also uses some rather nasty code to get the output of a command. It really really should not be this hard to do portably. To work around the fact that we cannot use runInteractiveProcess we instead have to create a temporary file. This also turns out to be a hack because the 'standard' openTempFile is not implemented except by GHC, so we now have a hacky version living in Distribution.Compat.TempFile just waiting for the standard openTempFile to be made properly portable, or for us to get some System.Process function that does what we want. ] [Fix the verbosity level for printing executed commands Duncan Coutts **20070430155054 Since 1 is the default verbosity level we should only print commands at level 2 and above. ] [initialBuildSteps should not actually build. Bryan O'Sullivan **20070424183841] [pretend that Cabal can build with nhc98 Malcolm.Wallace@cs.york.ac.uk**20070424104244] [minor tweaks to nhc98 branches of case distinctions Malcolm.Wallace@cs.york.ac.uk**20070212171419] [minor clarifications in doc of package descriptions Ross Paterson **20070423093806] [Fix for older GHCs, which exported a System.IO.try Ian Lynagh **20070419002443] [work around missing Control.Exception for nhc98 Malcolm.Wallace@cs.york.ac.uk**20070418230821] [Remove unnecessary import Ian Lynagh **20070418114407] [Fix imports Ian Lynagh **20070418110139] [Change variable name to match type change Ian Lynagh **20070418104811] [Fix Cabal's Setup.lhs after Maybe UserHooks / UserHooks change Duncan Coutts **20070418034619] [Behave the same on Windows and non-Windows Ian Lynagh **20070417230311] [Stop having hooks return an ExitCode that we then ignore Ian Lynagh **20070417225657] [Small tidyup Ian Lynagh **20070417225031] [Stop pretending we might not have any UserHooks Ian Lynagh **20070417224220] [Be better about exiting if a command we run fails Ian Lynagh **20070417222257] [Suggest that missing deps need to be downloaded and installed from hackage Ian Lynagh **20070417210158] [Make contents of SrcDist more useful to outside users. Bryan O'Sullivan **20070415060916 This change simply splits sdist into three functions. The normal sdist function remains unchanged from the caller's perspective, but it now consists of two phases, each an exported function. The source tree is prepared by prepareTree, and the archive is created by createArchive. This lets the cabal-rpm tool prepare a source tree and insert a few extra files into it before generating a tarball. ] [setup makefile: handle hs-source-dirs Simon Marlow **20070416140205 but only if there's a single entry for now. ] [setup makefile: use -p option to mkdir when making object directories Simon Marlow **20070416134720 I had a feeble attempt to avoid needing this originally, using $(sort ...) to create parents before children, but sometimes the parents aren't in the list, so it doesn't work. mkdir's -p option is POSIX, and I found it on all the platforms I checked (Linux, Solaris, Darwin, FreeBSD). ] [a couple of fixes to 'setup makefile' Simon Marlow **20070416133307 Put the -package-name flag at the beginning of GHC_OPTS, allowing it to be overriden later (as we do in the base package, for example). Also, add -split-objs if necessary. ] [remove illegal literal tabs in strings (again) Malcolm.Wallace@cs.york.ac.uk**20070416101220] [add missing support for .hs-boot/.lhs-boot with 'setup makefile' Simon Marlow **20070413152244] [Pass all the Cc/Ld flags to hsc2hs Ian Lynagh **20070413131318] [REINSTATE: Fix C/Haskell type mismatches Malcolm.Wallace@cs.york.ac.uk**20070412130607 This patch was previously applied and then rolled back. This new version imports System.Posix.Types.CPid correctly for nhc98. ] [Fix -Wall warnings Ian Lynagh **20070411004954] [-Wall fixes Ian Lynagh **20070411003509] [Remove duplicate import Ian Lynagh **20070410170930] [remove illegal tab chars in string literals Malcolm.Wallace@cs.york.ac.uk**20070410085626] [Use Distribution.Compat.FilePath.pathSeparator in Distribution.SetupWrapper, instead of having a local copy. bjorn@bringert.net**20070409165203] [Fix C/Haskell type mismatches Ian Lynagh *-20070404003510] [Rejig the adjacent checking in the unlitter Ian Lynagh **20070407173415 We were rejecting # 1 "foo" > ... in the HUnit package, claiming that it had a comment next to a program line. Now we treat anything cpp inserts as being blank. ] [parse (but don't pass on) options for ./configure Ian Lynagh **20070406153622] [Remove cabal-{builder,install,setup,upload} (now in separate repos) Ian Lynagh **20070405194729] [Add 'setup makefile' command Simon Marlow **20070309155022 'setup makefile' generates a Makefile that performs the steps necessary to compile the Haskell sources to object code. This only works for libraries, and only with GHC right now. Instead of simply 'setup build', you can do this: $ ./setup makefile $ make $ ./setup build where './setup makefile' does the preprocessing and generates a Makefile tailored to the current package. 'make' will build all the Haskell code to object files, and 'setup build' will build any C code and the library archives. The reason for all this is that you can say 'make -j' and get a parallel build, or you can say make dist/build/Foo.o EXTRA_HC_OPTS=-keep-s-file to compile a single file with extra options. ] [make Setup suitable for building the libraries with GHC Ian Lynagh **20061112214536] [Expose Distribution.Compat.ReadP Ian Lynagh **20061112214447] [Fix C/Haskell type mismatches Ian Lynagh **20070404003510] [Use rawSystemPath for calling tar rather than system Duncan Coutts **20070327110606 Means we get -v verboe output and better error messages if the command is not found. ] [Check the return value of tar Bryan O'Sullivan **20070326234148] [Fixed and improved Haddock comments sven.panne@aedion.de**20070322164427] [If we export ParseResult, we should export PError and PWarning, too sven.panne@aedion.de**20070322164340] [remove Makefile.inc (only affects nhc98) Malcolm.Wallace@cs.york.ac.uk**20070320120844] [Fixes compiling an executable for profiling with template haskell. Judah Jacobson **20070314012802] [rejig handling of continuation lines (fixes Cabal #118) Ross Paterson **20070311154610 Also avoids quadratic behaviour on long fields. ] [add Distribution.SetupWrapper to exposed-modules Simon Marlow *