From nominolo at googlemail.com Wed Aug 1 21:06:26 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Wed Aug 1 20:58:45 2007 Subject: darcs patch: Add impl(...) conditional to configurations. Message-ID: <46b12e12.2d09360a.3c8b.4987@mx.google.com> Thu Aug 2 03:05:27 CEST 2007 Thomas Schilling * Add impl(...) conditional to configurations. You can now use expressions like impl( ghc >= 6.6.1 ) in conditionals in .cabal files. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 14599 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070801/644ebf1a/attachment.bin From duncan.coutts at worc.ox.ac.uk Thu Aug 2 09:18:58 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 2 09:10:09 2007 Subject: Good Haskell Style In-Reply-To: <79d7c4980708020558p5a59fffbyeaccb942ecb100c@mail.gmail.com> References: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> <1186058388.5989.169.camel@localhost> <79d7c4980708020556l5afe2f5fkfe7155393e30c59@mail.gmail.com> <79d7c4980708020558p5a59fffbyeaccb942ecb100c@mail.gmail.com> Message-ID: <1186060739.5989.179.camel@localhost> On Thu, 2007-08-02 at 13:58 +0100, Alistair Bayley wrote: > > and the offending lines in this file are: > > > > #ifndef __HADDOCK__ > > deriving (Functor, Monad, MonadIO, MonadFix, MonadReader sess) > > #else > > -- Haddock can't cope with the "MonadReader sess" instance > > deriving (Functor, Monad, MonadIO, MonadFix) > > #endif > > > > so it would appear that __HADDOCK__ is not defined. > > Sorry, I should have said, "so it appears that -cpp is not being used". It uses -cpp if CPP is in the language extensions in the .cabal file. (At least that's what the code says it's supposed to be doing which is not a guarantee that it works). It does also define __HADDOCK__ when it uses cpp. Hmm, actually there is a problem here. Unlitting does indeed remove all the literate comments, so haddock will never see any markup that is put in the non-code part. To work with current haddock it'd have to be: > -- | This is a haddock comment > foo = ... because that's the only code haddock will see since unlitting turns a literate haskell file into a valid .hs file. It's a purely textual transformation and it's done by removing all the non > lines. Perhaps unlitting should be done by converting all literate comments into {- ... -} style comments. Then it'd probably work with haddock like you have it now: | haddock comment > foo = ... since that'd become: {- | haddock comment -} foo = ... Or something like that. Perhaps that's worth investigating and adding to ghc/cpphs or Cabal's own existing pure Haskell impl of unlitting. Duncan From jon.fairbairn at cl.cam.ac.uk Thu Aug 2 10:41:39 2007 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Aug 2 10:47:21 2007 Subject: Good Haskell Style References: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> <1186058388.5989.169.camel@localhost> <79d7c4980708020556l5afe2f5fkfe7155393e30c59@mail.gmail.com> <79d7c4980708020558p5a59fffbyeaccb942ecb100c@mail.gmail.com> <1186060739.5989.179.camel@localhost> <79d7c4980708020645o31ac94b4tcac3cd1bbec65118@mail.gmail.com> Message-ID: "Alistair Bayley" writes: > > It uses -cpp if CPP is in the language extensions in the .cabal file. > > So it does. So now Haddock completes, but produces very limited output. > > > Perhaps unlitting should be done by converting all literate comments > > into {- ... -} style comments. I have a programme (FishFeeder) that does this; it's a bit hacky, but I could post it here if someone was interested in taking it on. > As I alluded to earlier, I have a program which I wrote to do this. It > prefixes "--" rather than enclosing in {- -}, Mine uses {- -} and escapes any such present in comments. Here is the first comment from the source, which is itself literate haddock: | Preprocess literate haskell with Haddockumentation in the literate comments for use with Haddock. So making things a bit prettier Assumes that there is at least one space after every \">\", and indents the \"{-\"s (but not the \"-}\"s) by that much so that Haddock doesn't give a parse error. This is a bit of a hack, but I reckon it's haddock's fault since comments shouldn't have any effect on layout. > and it's not perfect I'd very be surprised if mine were! > (there are a number of cases it doesn't handle, although I'm of the > opinion that you shouldn't be doing whatever it fails on). I'm > thinking it might be feasible to distribute this in the Takusen > release and hook it into the cabal "setup haddock" command to > preprocess the .lhs files. It would surely be better to distribute a tool (either with compilers or with haddock) so that it worked for anyone who likes literate haskell? > I have been tempted to run it over our .lhs once and for all, and > convert everything to regular .hs files, but Oleg seems to like the > birdtrack style, so we've decided to stick with it for now. I much prefer the birdtrack style; it's a matter of taste, and there's nothing more likely to cause disaffection than insisting that someone abide by someone else's taste. I would hate to see it deprecated just because the tools were no good. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From duncan.coutts at worc.ox.ac.uk Thu Aug 2 11:32:48 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Aug 2 11:23:57 2007 Subject: Good Haskell Style In-Reply-To: References: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> <1186058388.5989.169.camel@localhost> <79d7c4980708020556l5afe2f5fkfe7155393e30c59@mail.gmail.com> <79d7c4980708020558p5a59fffbyeaccb942ecb100c@mail.gmail.com> <1186060739.5989.179.camel@localhost> <79d7c4980708020645o31ac94b4tcac3cd1bbec65118@mail.gmail.com> Message-ID: <1186068768.5989.185.camel@localhost> On Thu, 2007-08-02 at 15:41 +0100, Jon Fairbairn wrote: > "Alistair Bayley" writes: > > > > It uses -cpp if CPP is in the language extensions in the .cabal file. > > > > So it does. So now Haddock completes, but produces very limited output. > > > > > Perhaps unlitting should be done by converting all literate comments > > > into {- ... -} style comments. > > I have a programme (FishFeeder) that does this; it's a bit > hacky, but I could post it here if someone was interested in > taking it on. Sure why not. Post it. As I say, we've already got unlit code in Cabal. If anyone wants to then make a patch to Cabal's unlit code that'd be much appreciated. Then we can ask Alistair to use Takusen as a test case. Or we could see about getting it into cpphs's --unlit mode. Duncan From jon.fairbairn at cl.cam.ac.uk Thu Aug 2 11:40:26 2007 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu Aug 2 11:37:26 2007 Subject: Good Haskell Style References: <125EACD0CAE4D24ABDB4D148C4593DA901BDFBCC@GBLONXMB02.corp.amvescap.net> <1186058388.5989.169.camel@localhost> <79d7c4980708020556l5afe2f5fkfe7155393e30c59@mail.gmail.com> <79d7c4980708020558p5a59fffbyeaccb942ecb100c@mail.gmail.com> <1186060739.5989.179.camel@localhost> <79d7c4980708020645o31ac94b4tcac3cd1bbec65118@mail.gmail.com> <1186068768.5989.185.camel@localhost> Message-ID: Duncan Coutts writes: > On Thu, 2007-08-02 at 15:41 +0100, Jon Fairbairn wrote: > > "Alistair Bayley" writes: > > > > > > It uses -cpp if CPP is in the language extensions in the .cabal file. > > > > > > So it does. So now Haddock completes, but produces very limited output. > > > > > > > Perhaps unlitting should be done by converting all literate comments > > > > into {- ... -} style comments. > > > > I have a programme (FishFeeder) that does this; it's a bit > > hacky, but I could post it here if someone was interested in > > taking it on. > > Sure why not. Post it. As I say, we've already got unlit code in Cabal. OK, but as I said, it's hacky... -------------- next part -------------- A non-text attachment was scrubbed... Name: Main.lhs Type: application/haskell Size: 2832 bytes Desc: FishFeeder/Main.lhs Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070802/1564f5e3/Main-0001.bin -------------- next part -------------- -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From nominolo at googlemail.com Fri Aug 3 08:58:44 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Aug 3 08:50:58 2007 Subject: darcs patch: Add documentation for Cabal Configurations. Message-ID: <46b32684.1d0c360a.0726.ffffea47@mx.google.com> Fri Aug 3 14:56:32 CEST 2007 Thomas Schilling * Add documentation for Cabal Configurations. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 34787 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070803/28fd9b2f/attachment-0001.bin From nominolo at googlemail.com Fri Aug 3 14:31:45 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Aug 3 14:23:58 2007 Subject: darcs patch: Fix tab in Cabal.cabal. (and 1 more) Message-ID: <46b37491.4301360a.306b.ffff83f0@mx.google.com> Fri Aug 3 19:57:01 CEST 2007 Thomas Schilling * Fix tab in Cabal.cabal. Fri Aug 3 20:12:44 CEST 2007 Thomas Schilling * Disallow tabs .cabal files with new syntax -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 17712 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070803/bb2b7f44/attachment.bin From nominolo at googlemail.com Fri Aug 3 17:34:14 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Aug 3 17:26:27 2007 Subject: darcs patch: Fix printing of 'impl' checks. (and 2 more) Message-ID: <46b39f56.2d09360a.3c8b.ffffcd16@mx.google.com> Fri Aug 3 22:06:22 CEST 2007 Thomas Schilling * Fix printing of 'impl' checks. Fri Aug 3 22:08:29 CEST 2007 Thomas Schilling * Fix import path to HUnit. Fri Aug 3 23:33:31 CEST 2007 Thomas Schilling * Change error message for tabs used as indentation to something more helpful. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 13018 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070803/cb1b56d0/attachment-0001.bin From duncan.coutts at worc.ox.ac.uk Fri Aug 3 18:14:30 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Aug 3 18:05:33 2007 Subject: packages with UTF8 in people's names Message-ID: <1186179270.5989.237.camel@localhost> Hi Sascha, We got a bug report the other day that someone could not upload a cabal package that had their name containing UTF8 chars. We were wondering if you could look into it. Here's another similar one: http://hackage.haskell.org/trac/hackage/ticket/145 it may well be that the best way to fix this is in Cabal. We could make sure that Cabal returns properly decoded Strings for all the free-form fields. Tell us if you want particular changes in the Cabal library for that. Duncan From duncan.coutts at worc.ox.ac.uk Fri Aug 3 18:39:57 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Aug 3 18:30:59 2007 Subject: what is --scratchdir= for? Message-ID: <1186180797.5989.247.camel@localhost> It's not clear to me what the configure --scratchdir= option is for. It seems to be only used by hugs for building and installing and it defaults to dist/scratch. We don't allow any of the other locations under dist/scratch to be overridden, probably because there's not much point in that. Why do we need it for hugs? If we're going to have an option like this it should probably set the location of the whole dist/ directory hierarchy. Though that has its own problems since we'd need to have --scratchdir= as a global option to each command since we put the saved config info into $dist/ . In the mean time, if we're keeping dist/ fixed then we can always just rm -rf dist when doing a clean, fixing bug #92. If we allow the user to override $dist then we'd have to be a bit more removing it since the user could set it to some shared temp dir. Duncan From nominolo at googlemail.com Fri Aug 3 18:50:30 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Aug 3 18:42:42 2007 Subject: darcs patch: Fix haddock comment. Message-ID: <46b3b136.2d09360a.3c8b.ffffeba8@mx.google.com> Sat Aug 4 00:49:56 CEST 2007 Thomas Schilling * Fix haddock comment. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 12573 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070803/5f5b8a36/attachment.bin From ross at soi.city.ac.uk Sat Aug 4 09:44:25 2007 From: ross at soi.city.ac.uk (ross@soi.city.ac.uk) Date: Sat Aug 4 09:36:59 2007 Subject: Hackage rocks In-Reply-To: <1185806613.5721.77.camel@localhost> References: <1185806613.5721.77.camel@localhost> Message-ID: <1186235065.46b482b9b45d9@fred.soi.city.ac.uk> Quoting Duncan Coutts : > * haddock docs not building. This is very common. The most common > parse problem is un-escaped / chars. This seems to trip people > up a lot. I wonder if we could make haddock's parser grok this > better? For example most uses of ' don't cause problems, eg > "don't". I wonder if we could have a similar rule for / so that > things like "I/O" didn't get recognised as beginning an > emphasised section. Perhaps the rule should be that / but be at > the beginning or end of a token, so a " / " or a "X/Y" would not > count, only "/beginning" or "ends/" of words? Like Ian, I'm not sure that complicating haddock is the way to go. It doesn't seem unreasonable to expect people to test build their packages, including with haddock, before making a release. > * inability to automatically find/generate dependencies on > external packages like C libraries. Many packages that use FFI > need to link to non-standard C libs and it's not always obvious > what packages they need. Of course, specifying external libs is > not simple since different platforms often call them different > things, but perhaps we could have some non-binding hint fields. > Or perhaps we should just try and guess based on the names of > the libs that need to be linked to (though that doesn't cover > deps on other programs rather than C libs). This is a hard one, because the packages you need will vary between systems, e.g. between Debian and Gentoo, let alone Unix vs Windows. It may be necessary to have a little extra information for each system. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From duncan.coutts at worc.ox.ac.uk Sat Aug 4 10:06:33 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Aug 4 09:57:38 2007 Subject: Hackage rocks In-Reply-To: <1186235065.46b482b9b45d9@fred.soi.city.ac.uk> References: <1185806613.5721.77.camel@localhost> <1186235065.46b482b9b45d9@fred.soi.city.ac.uk> Message-ID: <1186236393.5989.293.camel@localhost> On Sat, 2007-08-04 at 14:44 +0100, ross@soi.city.ac.uk wrote: > Quoting Duncan Coutts : > > * haddock docs not building. This is very common. The most common > > parse problem is un-escaped / chars. This seems to trip people > > up a lot. I wonder if we could make haddock's parser grok this > > better? For example most uses of ' don't cause problems, eg > > "don't". I wonder if we could have a similar rule for / so that > > things like "I/O" didn't get recognised as beginning an > > emphasised section. Perhaps the rule should be that / but be at > > the beginning or end of a token, so a " / " or a "X/Y" would not > > count, only "/beginning" or "ends/" of words? > > Like Ian, I'm not sure that complicating haddock is the way to go. It doesn't > seem unreasonable to expect people to test build their packages, including > with haddock, before making a release. Simon is having a look at this issue. But yes, getting people to test would be good. We can do this with our tools, eg cabal-upload and/or a cabal lint command or something. > > * inability to automatically find/generate dependencies on > > external packages like C libraries. Many packages that use FFI > > need to link to non-standard C libs and it's not always obvious > > what packages they need. Of course, specifying external libs is > > not simple since different platforms often call them different > > things, but perhaps we could have some non-binding hint fields. > > Or perhaps we should just try and guess based on the names of > > the libs that need to be linked to (though that doesn't cover > > deps on other programs rather than C libs). > > This is a hard one, because the packages you need will vary between systems, > e.g. between Debian and Gentoo, let alone Unix vs Windows. It may be necessary > to have a little extra information for each system. I'm not sure it's that hard. Distros have weirder naming conventions than upstream packages typically do. So we can target the upstream name and let distros map that to their package names in whatever way they can. So I'm not asking for a 100% sure mapping to system packages, but a reasonable hint. For example: pcre; the upstream project call it "pcre" and release pcre.-x.y.tar.gz packages. Gentoo calls it dev-libs/libpcre and debian calls it libpcre3 but that's their problem really. Just having this hint at least tells us that we have a dep we should try to satisfy by mapping it to some system package name. Not knowing of the dependency at all until the package fails to build is surely worse. Another example: darcs-graph depends on the gnuplot program at runtime. This one is a totally untracked dependency unlike the pcre example where we at least have the hint of pcre in the extra-libraries: field. Again, the name is not that ambiguous, it's sci-visualization/gnuplot on gentoo and gnuplot on debian. So getting this perfect is too hard, but having some useful information would really help in many situations, eg for hackage's auto-builder, cabal-install and generating distro packages from cabal packages. Duncan From duncan.coutts at worc.ox.ac.uk Sat Aug 4 10:09:25 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Aug 4 10:00:27 2007 Subject: hacking cabal is too hard... Message-ID: <1186236565.5989.297.camel@localhost> so what can we do about it? Some barriers to entry: 1. reporting bugs requires logging in, many people still miss this. 2. bug reports get ignored (which is disheartening to users) because... 3. bug reports do not get reported to this list (like ghc ones get reported to the ghc-bugs list). This also means we get no public discussion going on most bugs, and the people who finally close bugs get no public recognition. 4. there is no cabal hacking guide, a short guide to the source code and style would help (eg explaining the main environments functions operate in, ie BuildInfo, LocalBuildInfo). Simple things like adding fields, commands or new flags. 5. it's not clear if it's possible to set up a local hackage servers to help test & hack on the hackage web code. 6. darcs sending patches get rejected by default since the cabal-devel list is subscriber only. Probably more things. People often complain that the internal Cabal code is hard to understand, which is partly true though it's also related to point 4. cabal-install should be easy to hack and there's not a lot to do to make it really work well. We need to get someone to take an interest in it. It should be a cool program to hack on because it should have a huge number of users eventually. It's also important to get this going now since the hackage web site is working better and better with more and more packages and we want to bundle cabal-install with the upcoming ghc release. Hacking infrastructure should be cool because so many people use it. We need to lower the barriers to entry, get more people involved and reward contributers with greater public recognition. We also need more people to review patches. I'm not always especially quick at responding to the few patches we do get contributed. Then of course there's just doing a bit of evangelism to try and get more contributers, eg blog postings or emails to the libraries and -cafe lists. Sorry for the rant, I've been hacking on cabal for a few days. I think it must have made me bitter or tired or something. Quick hacking report: Thomas committed a series of 57 patches to add the new configurations system. Since then Thomas and I have committed 54 patches and closed several bug reports. We were trying some more radical refactorings, like pulling the compiler support out into a proper Compiler abstraction rather than each bit of code embedding per-compiler code locally. That turned out to be a bit too difficult at the moment. I can give a more detailed explanation if anyone else wants to have a go. Similarly we were considering making some of the common environments into proper monads, eg we have many environments with PackageDescription, LocalBuildInfo and Verbosity. But this impacts on the hooks api, again. Duncan From ndmitchell at gmail.com Sat Aug 4 12:54:13 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat Aug 4 12:46:25 2007 Subject: Cabal and testing Message-ID: <404396ef0708040954l4ec42a1dmfe0946de1ac005ed@mail.gmail.com> Hi I'm just about to hook up Cabal for doing some testing, so I started with the obvious template: import Distribution.Simple main = defaultMainWithHooks defaultUserHooks{runTests=test} test :: Args -> Bool -> PackageDescription -> LocalBuildInfo -> IO ExitCode test args bool pd lbi = return ExitSuccess A few questions about this interface: 1) What on earth is "bool"? Perhaps either a haddock comment, or a type alias would make it more clear. 2) If the tests fail to run, ExitFailure would be appropriate. If the tests run and pass then ExitSuccess seems sensible. If the tests run, but fail, what should be returned? 3) On failure should I "print" something, or just "error" out? Thanks Neil From duncan.coutts at worc.ox.ac.uk Sat Aug 4 13:18:23 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Aug 4 13:09:23 2007 Subject: Cabal and testing In-Reply-To: <404396ef0708040954l4ec42a1dmfe0946de1ac005ed@mail.gmail.com> References: <404396ef0708040954l4ec42a1dmfe0946de1ac005ed@mail.gmail.com> Message-ID: <1186247903.5989.302.camel@localhost> On Sat, 2007-08-04 at 17:54 +0100, Neil Mitchell wrote: > Hi > > I'm just about to hook up Cabal for doing some testing, so I started > with the obvious template: > > import Distribution.Simple > main = defaultMainWithHooks defaultUserHooks{runTests=test} > > test :: Args -> Bool -> PackageDescription -> LocalBuildInfo -> IO ExitCode > test args bool pd lbi = return ExitSuccess > > A few questions about this interface: > > 1) What on earth is "bool"? Perhaps either a haddock comment, or a > type alias would make it more clear. No idea :-) Cabal currently passes False if that helps you at all :-) > 2) If the tests fail to run, ExitFailure would be appropriate. If the > tests run and pass then ExitSuccess seems sensible. If the tests run, > but fail, what should be returned? In the current Cabal version all the hooks that used to return IO ExitCode now return just IO (). So the behaviour you want to use going forward is to just throw an exception / IOError. > 3) On failure should I "print" something, or just "error" out? Both. You can use something like: Distribution.Simple.Utils.die "tests failed blah blah blah" Duncan From lemming at henning-thielemann.de Sat Aug 4 16:32:24 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Aug 4 16:24:32 2007 Subject: Hackage rocks In-Reply-To: <1185806613.5721.77.camel@localhost> References: <1185806613.5721.77.camel@localhost> Message-ID: On Mon, 30 Jul 2007, Duncan Coutts wrote: > * inability to automatically find/generate dependencies on > external packages like C libraries. Many packages that use FFI > need to link to non-standard C libs and it's not always obvious > what packages they need. Of course, specifying external libs is > not simple since different platforms often call them different > things, but perhaps we could have some non-binding hint fields. > Or perhaps we should just try and guess based on the names of > the libs that need to be linked to (though that doesn't cover > deps on other programs rather than C libs). How about asking the distribution specific package manager program to which package the library file belongs? However, this requires that the dependent package is installed on the packaging machine. From eivuokko at gmail.com Sun Aug 5 18:05:21 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Sun Aug 5 18:06:07 2007 Subject: Developing cabal2wix - building Windows installers automatically Message-ID: <46B649A1.3000604@gmail.com> Hi, I decided to try to build a cabal -> wix converter, cabal2wix, to make it easier to generate Windows installers for cabal-packages. My main target is ghc-compiled libraries. There are few issues I've ran into and I'd appreciate any comments on them. I'll try to publish the darcs repo somewhere if there's interest. Some of the issues are gray, as I don't understand all the details myself, and reading Cabal's code isn't very enlightening. Issue 1: Cabal puts (at least) docs under Program Files\Common Files - this separates docs from other parts of the program by logical placing, which is pretty annoying if you need to offer way to relocate installation (say to user's home directory). I am considering moving docs next to library files in installers cabal2wix generates. Issue 2: setup copy --destdir=foo is confusing in Windows. If my prefix is c:\Program Files (like it is if I run configure without options), the directory structure after copy is foo\Program Files - ie. unsuable locally because drive letter is missing, and unusable at remote locations, because Program Files is not localized. I'd like not to use all possible directory flags at configure time, because it is impossible to know how different packages react to them. (currently cabal2wix assumes no directories were changed.) Suggestion: Make copy-hook unable to copy random files on their own, this way there could be setup copy --list-links, which would be nicer, IMHO. As the list could also differentiate between different types of files. Profiling lib, shared libs (dev and end-user installer in one.) Issue 3: Currently cabal2wix reads dist\setup-config to find out package and compiler information. This is pretty stupid, as LocalBuildInfo structure might not be that stable, and cabal2wix can only guarantee working with the same Cabal it was built with. cabal2wix could read installed-pkg-config (and maybe .cabal) to get package name and version. But I can't see how to get compiler information from any other place than setup-config. It'd also make sense to read solved build-depends info, but I currently don't have plans to do that. Issue 4: There is no proper registry keys for finding compiler installation. Neil's installer adds HKCU\Software\Haskell\GHC\InstallDir. I'd much prefer if the registry key path contained ghc version in it, and HKLM might be preferable on some multi-user machines. It'd be great if we could find recommended location for this info. (And use it for ghc 6.8 releases) My tentative proposal: Use HKLM if "all users" install, HKCU otherwise. Use \Software\Haskell\COMPILER\VERSION\InstallDir for storing path to base location of installed compiler. (i.e. it shouldn't point to bin-directory.) Small issues: * License file is not installed. * Docs need relinking at install location, that's a bit annoying. Big thank you for Duncan and Ian for useful comments at irc. Issue list is shorter now ;-) Thanks, Esa From ndmitchell at gmail.com Sun Aug 5 19:04:30 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Aug 5 18:56:37 2007 Subject: Developing cabal2wix - building Windows installers automatically In-Reply-To: <46B649A1.3000604@gmail.com> References: <46B649A1.3000604@gmail.com> Message-ID: <404396ef0708051604k285bc21dh79e54fd5e1bdf205@mail.gmail.com> Hi > I decided to try to build a cabal -> wix converter, cabal2wix, to make > it easier to generate Windows installers for cabal-packages. My main > target is ghc-compiled libraries. There are few issues I've ran into > and I'd appreciate any comments on them. I found wix annoying, and chose to use InnoSetup instead, following on from Duncan's use of it in Gtk2hs. Inno can't do .msi's. > I'll try to publish the darcs repo somewhere if there's interest. If there was some way to get Hugs and GHC installers out of it, possibly with a fake cabal file or something, that would be lovely! Perhaps a System.Installer.Wix library that all could use? > Cabal puts (at least) docs under Program Files\Common Files - this > separates docs from other parts of the program by logical placing, > which is pretty annoying if you need to offer way to relocate > installation (say to user's home directory). I am considering moving > docs next to library files in installers cabal2wix generates. I would very much like it if runhaskell Setup install, and running your installer generator did the same thing. > I'd like not to use all possible directory flags at configure time, > because it is impossible to know how different packages react to them. > (currently cabal2wix assumes no directories were changed.) I think you can currently assume no Windows user has ever successfully used them! > Issue 4: > There is no proper registry keys for finding compiler installation. > Neil's installer adds HKCU\Software\Haskell\GHC\InstallDir. I'd much > prefer if the registry key path contained ghc version in it, and > HKLM might be preferable on some multi-user machines. I copied what the previous installer had, and we only no what the previous installer had because Duncan was relying on it for Gtk2hs (the previous installer is closed source). Make a concrete suggestion, file it as a GHC bug and I'm sure it can be done/ > My tentative proposal: Use HKLM if "all users" install, HKCU otherwise. > Use \Software\Haskell\COMPILER\VERSION\InstallDir for storing path to > base location of installed compiler. (i.e. it shouldn't point to > bin-directory.) Agreed. > Small issues: > * License file is not installed. On Windows, I doubt anyone cares :-) Thanks for doing this, it has been something I've been meaning to get to for ages. Thanks Neil From eivuokko at gmail.com Sun Aug 5 21:28:47 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Sun Aug 5 21:20:53 2007 Subject: Developing cabal2wix - building Windows installers automatically In-Reply-To: <404396ef0708051604k285bc21dh79e54fd5e1bdf205@mail.gmail.com> References: <46B649A1.3000604@gmail.com> <404396ef0708051604k285bc21dh79e54fd5e1bdf205@mail.gmail.com> Message-ID: Hi, On 8/6/07, Neil Mitchell wrote: > I found wix annoying, and chose to use InnoSetup instead, following on > from Duncan's use of it in Gtk2hs. Inno can't do .msi's. I chose Wix because I wanted to understand Wix and MSI's structure better. > > I'll try to publish the darcs repo somewhere if there's interest. > > If there was some way to get Hugs and GHC installers out of it, > possibly with a fake cabal file or something, that would be lovely! > Perhaps a System.Installer.Wix library that all could use? I doubt compiler installers can be generated so easily. Btw, cabal2wix doesn't really need .cabal file for anything - it just reads what setup copy --destdir=dist\cabal2wix generates, and build configs. Library isn't my target for now, at least. On that scale, it might also be nicer to generate msi's directly, rather than generating xml. > > My tentative proposal: Use HKLM if "all users" install, HKCU otherwise. > > Use \Software\Haskell\COMPILER\VERSION\InstallDir for storing path to > > base location of installed compiler. (i.e. it shouldn't point to > > bin-directory.) > > Agreed. Oops. I think it's already doing almost that, I just read my registry extract wrong. > > Small issues: > > * License file is not installed. > > On Windows, I doubt anyone cares :-) I do. And I need the file for license agreement dialog :-) Best regards, --Esa From simonmarhaskell at gmail.com Mon Aug 6 04:48:17 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Aug 6 04:40:26 2007 Subject: Broken head In-Reply-To: <46B68B04.9000202@cse.unsw.edu.au> References: <46B68B04.9000202@cse.unsw.edu.au> Message-ID: <46B6E051.4010107@gmail.com> Manuel M T Chakravarty wrote: > Running validate on the current (Mon Aug 6 12:42:45 EST 2007) head, > gives me > > /opt/local/bin/ghc -H64m -Onot -fasm -I. -Iinclude -Rghc-timing -O > -fasm -ignore-package Cabal -ignore-package filepath -I../libraries > -fglasgow-exts -no-recomp -c Distribution/System.hs -o > Distribution/System.o -ohi Distribution/System.hi > > ../libraries/Cabal/Distribution/System.hs:14:10: > Not in scope: `System.Info.os' > > This is on MacOS compiling with GHC 6.6.1. > > Duncan, did you run validate before pushing all these recent cabal patches? We shouldn't expect Cabal developers to run GHC's validate when pushing patches. The right thing to do is for GHC to use a branch of Cabal (subset only, so no conflicts), and only push patches to GHC's branch after a validate. This entails some extra overhead to the development model. Thoughts? Cheers, Simon From simonmarhaskell at gmail.com Mon Aug 6 05:16:35 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Aug 6 05:08:43 2007 Subject: hacking cabal is too hard... In-Reply-To: <1186236565.5989.297.camel@localhost> References: <1186236565.5989.297.camel@localhost> Message-ID: <46B6E6F3.50808@gmail.com> Duncan Coutts wrote: > so what can we do about it? BTW, thanks for all the cleanup you did over the weekend, looks great. > Some barriers to entry: > > 1. reporting bugs requires logging in, many people still miss > this. > 2. bug reports get ignored (which is disheartening to users) > because... > 3. bug reports do not get reported to this list (like ghc ones get > reported to the ghc-bugs list). This also means we get no public > discussion going on most bugs, and the people who finally close > bugs get no public recognition. The Trac configuration is set to auto CC this list with bug updates, but the mailing list config needs to be updated to allow them through. Isaac is the only one with admin permissions on the list at the moment, should we add more people? Volunteers? > 4. there is no cabal hacking guide, a short guide to the source > code and style would help (eg explaining the main environments > functions operate in, ie BuildInfo, LocalBuildInfo). Simple > things like adding fields, commands or new flags. > 5. it's not clear if it's possible to set up a local hackage > servers to help test & hack on the hackage web code. > 6. darcs sending patches get rejected by default since the > cabal-devel list is subscriber only. Again, this is a mailing-list setup issue. cabal-devel should do the same as cvs-ghc, and moderate by default (but someone needs to do the moderation). > Probably more things. > > People often complain that the internal Cabal code is hard to > understand, which is partly true though it's also related to point 4. ...and I think a lot can be done to improve things incrementally. There are abstractions that are not consistently used (eg. Program, but it sounds like you've improved things here), and missing abstractions (compiler-specific stuff is not sufficiently abstracted). There are over-complex abstractions: e.g. hooks. There are not-very abstractions: the "simple" build system is wired-in when it was originally intended to be layered on top of the basic infrastructure. I'm not sure whether we should abandon this layering or try to do it properly. All this has arisen because Cabal has been hacked on by a wide range of people, few of whom really took an interest in the design of the system as a whole. Mostly we were trying to get the job done and make Cabal do what we needed, which to a large extent it does. But this is fertile ground for hackers who enjoy cleaning things up and refactoring... > cabal-install should be easy to hack and there's not a lot to do to make > it really work well. We need to get someone to take an interest in it. > It should be a cool program to hack on because it should have a huge > number of users eventually. It's also important to get this going now > since the hackage web site is working better and better with more and > more packages and we want to bundle cabal-install with the upcoming ghc > release. > > Hacking infrastructure should be cool because so many people use it. We > need to lower the barriers to entry, get more people involved and reward > contributers with greater public recognition. We also need more people > to review patches. I'm not always especially quick at responding to the > few patches we do get contributed. > > Then of course there's just doing a bit of evangelism to try and get > more contributers, eg blog postings or emails to the libraries and -cafe > lists. > > > Sorry for the rant, I've been hacking on cabal for a few days. I think > it must have made me bitter or tired or something. thanks for bringing this up, it's definitely important. Cabal is fundamental to the Haskell community now, we should look after it. > Quick hacking report: > Thomas committed a series of 57 patches to add the new configurations > system. Since then Thomas and I have committed 54 patches and closed > several bug reports. We were trying some more radical refactorings, like > pulling the compiler support out into a proper Compiler abstraction > rather than each bit of code embedding per-compiler code locally. That > turned out to be a bit too difficult at the moment. I can give a more > detailed explanation if anyone else wants to have a go. Similarly we > were considering making some of the common environments into proper > monads, eg we have many environments with PackageDescription, > LocalBuildInfo and Verbosity. But this impacts on the hooks api, again. Great! Cheers, Simon From duncan.coutts at worc.ox.ac.uk Mon Aug 6 06:16:59 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Aug 6 06:07:57 2007 Subject: Broken head In-Reply-To: <46B6EB40.7060304@cse.unsw.edu.au> References: <46B68B04.9000202@cse.unsw.edu.au> <46B6E051.4010107@gmail.com> <46B6EB40.7060304@cse.unsw.edu.au> Message-ID: <1186395419.25415.14.camel@localhost> On Mon, 2007-08-06 at 19:34 +1000, Manuel M T Chakravarty wrote: > >> ../libraries/Cabal/Distribution/System.hs:14:10: > >> Not in scope: `System.Info.os' > >> > >> This is on MacOS compiling with GHC 6.6.1. > >> > >> Duncan, did you run validate before pushing all these recent cabal > >> patches? No. I checked that it built on it's own and passed some of it's own regression tests. > > We shouldn't expect Cabal developers to run GHC's validate when pushing > > patches. The right thing to do is for GHC to use a branch of Cabal > > (subset only, so no conflicts), and only push patches to GHC's branch > > after a validate. > > > > This entails some extra overhead to the development model. Thoughts? > > Depends on the Cabal developers, I guess. Making sure that GHC's > build doesn't break might be a good regression test for Cabal. If > they don't like that, using a subset-branch sounds fine (something > like packages/Cabal-ghc). Problem is, checking that Cabal builds fine is no guarantee that ghc builds with it. For example ghc uses lots of compat/Distribution/*.hs files (that merely #include some real Cabal/Distribution/*.hs files) and if we make slight module dep changes in Cabal it requires adding more such files. That was the source of one recent break, though not the System.Info.os one. So yes, we'd have to run the full ghc validate script. If possible I'd rather avoid making all Cabal contributers do that since we're trying to make Cabal development more assessable. > However, this raises the general question of GHC's core packages. > Cabal might be a special case, but generally validate is only > moderately useful (as we just saw) unless the obligation to run it > applies to all core packages of GHC. (I don't think it makes sense > to use subset-branches for all core packages.) But even if we did run validate, sometimes we do have to make breaking changes to the Cabal interface. Especially in this development cycle we've been trying to get all the breaking changes through so we can I'm not sure it's ok to ask Cabal contributers to not only run validate after making api changes, but also to fix ghc and all core packages that break due to that. It's too heavy. IMHO, our main problem in Cabal is lack of development progress rather than too many changes too quickly. So what to do? One thing I suggested previously was a way of making temporary branches and feeding them to the build bots. So we could push these kinds of changes to such a branch and see what the fallout is without breaking the main tree. It'd need some automation to make it manageable I suspect. Perhaps it should be something where the core branch pulls upstream changes into the temp branch and runs them through the build bots, using the last buildable ghc, then if it builds it gets pulled through to the branches that ghc uses. So it'd still be automatic in the usual non-breaking case. In the breaking case we get an email and the changes do not propagate into the ghc head branches. Duncan From duncan.coutts at worc.ox.ac.uk Mon Aug 6 07:35:17 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Aug 6 07:26:10 2007 Subject: Hackage rocks In-Reply-To: References: <1185806613.5721.77.camel@localhost> Message-ID: <1186400117.25415.33.camel@localhost> On Sat, 2007-08-04 at 22:32 +0200, Henning Thielemann wrote: > On Mon, 30 Jul 2007, Duncan Coutts wrote: > > > * inability to automatically find/generate dependencies on > > external packages like C libraries. Many packages that use FFI > > need to link to non-standard C libs and it's not always obvious > > what packages they need. Of course, specifying external libs is > > not simple since different platforms often call them different > > things, but perhaps we could have some non-binding hint fields. > > Or perhaps we should just try and guess based on the names of > > the libs that need to be linked to (though that doesn't cover > > deps on other programs rather than C libs). > > How about asking the distribution specific package manager program to > which package the library file belongs? However, this requires that the > dependent package is installed on the packaging machine. Yes, for C libraries it's a pretty good hint. It doesn't help us with dependencies on programs or non-C libs however. Duncan From duncan.coutts at worc.ox.ac.uk Mon Aug 6 09:26:43 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Aug 6 09:17:38 2007 Subject: Developing cabal2wix - building Windows installers automatically In-Reply-To: <46B649A1.3000604@gmail.com> References: <46B649A1.3000604@gmail.com> Message-ID: <1186406803.25415.52.camel@localhost> On Mon, 2007-08-06 at 01:05 +0300, Esa Ilari Vuokko wrote: > Hi, > > I decided to try to build a cabal -> wix converter, cabal2wix, to make > it easier to generate Windows installers for cabal-packages. My main > target is ghc-compiled libraries. There are few issues I've ran into > and I'd appreciate any comments on them. > > I'll try to publish the darcs repo somewhere if there's interest. > > Some of the issues are gray, as I don't understand all the details > myself, and reading Cabal's code isn't very enlightening. > > Issue 1: > Cabal puts (at least) docs under Program Files\Common Files - this > separates docs from other parts of the program by logical placing, > which is pretty annoying if you need to offer way to relocate > installation (say to user's home directory). I am considering moving > docs next to library files in installers cabal2wix generates. > > Issue 2: > setup copy --destdir=foo is confusing in Windows. If my prefix is > c:\Program Files (like it is if I run configure without options), > the directory structure after copy is foo\Program Files - ie. unsuable > locally because drive letter is missing, It's not clear that's true, if you copy the files in foo\Program Files\ to C:\Program Files\ and register the package with ghc-pkg then it should work fine. > and unusable at remote > locations, because Program Files is not localized. > I'd like not to use all possible directory flags at configure time, > because it is impossible to know how different packages react to them. I'm not sure why you say that; what they mean does not vary between packages. I think setting the prefix and other directory flags should be fine. Since you want a relocatable package you do want to set prefix as ".". As you said, some of the other bits are not relative to prefix on windows, like the docs. So that's a problem. > (currently cabal2wix assumes no directories were changed.) > Suggestion: Make copy-hook unable to copy random files on their own, > this way there could be setup copy --list-links, which would be > nicer, IMHO. As the list could also differentiate between different > types of files. Profiling lib, shared libs (dev and end-user > installer in one.) I don't think it's a problem that cabal doesn't support this since it's easy to generate an install image by copying into a temp dir. This is the way most other build systems work (both unix and windows ones). All you'd be saving is one bunch of file copies which is really pretty cheap. > Issue 3: > Currently cabal2wix reads dist\setup-config to find out package and > compiler information. This is pretty stupid, as LocalBuildInfo > structure might not be that stable, and cabal2wix can only guarantee > working with the same Cabal it was built with. > cabal2wix could read installed-pkg-config (and maybe .cabal) to get > package name and version. But I can't see how to get compiler > information from any other place than setup-config. You an do that by calling functions in the Simple build system. > It'd also make sense to read solved build-depends info, but I currently > don't have plans to do that. Similarly. > Big thank you for Duncan and Ian for useful comments at irc. Issue list > is shorter now ;-) Good :-) This is potentially a very useful project. We do have lots of windows users and we don't yet have things as easy for them as we should. In the long term we would want to tie this into the hackage build server to build binary packages and the cabal-install tool to download and install them. Duncan From duncan.coutts at worc.ox.ac.uk Mon Aug 6 09:27:17 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Aug 6 09:18:10 2007 Subject: Developing cabal2wix - building Windows installers automatically In-Reply-To: <404396ef0708051604k285bc21dh79e54fd5e1bdf205@mail.gmail.com> References: <46B649A1.3000604@gmail.com> <404396ef0708051604k285bc21dh79e54fd5e1bdf205@mail.gmail.com> Message-ID: <1186406837.25415.54.camel@localhost> On Mon, 2007-08-06 at 00:04 +0100, Neil Mitchell wrote: > > Cabal puts (at least) docs under Program Files\Common Files - this > > separates docs from other parts of the program by logical placing, > > which is pretty annoying if you need to offer way to relocate > > installation (say to user's home directory). I am considering moving > > docs next to library files in installers cabal2wix generates. > > I would very much like it if runhaskell Setup install, and running > your installer generator did the same thing. Yes they should be the same, but what is the rationale for using Program Files\Common Files for docs? Don't most Windows apps install into a single relocatable directory rather than putting files in many places? A similar issue arises for that common Haskell tool bin directory we're using on windows. Duncan From ndmitchell at gmail.com Mon Aug 6 09:59:59 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Aug 6 09:52:02 2007 Subject: Developing cabal2wix - building Windows installers automatically In-Reply-To: <1186406837.25415.54.camel@localhost> References: <46B649A1.3000604@gmail.com> <404396ef0708051604k285bc21dh79e54fd5e1bdf205@mail.gmail.com> <1186406837.25415.54.camel@localhost> Message-ID: <404396ef0708060659s57fba73du6e21b953adeacbc9@mail.gmail.com> Hi > > I would very much like it if runhaskell Setup install, and running > > your installer generator did the same thing. > > Yes they should be the same, but what is the rationale for using Program > Files\Common Files for docs? Don't most Windows apps install into a > single relocatable directory rather than putting files in many places? > > A similar issue arises for that common Haskell tool bin directory we're > using on windows. Otherwise you need to add a lot of things to the path, once per installer. Windows wasn't really designed for lots of console apps, Haskell isn't really designed for lots of GUI apps - here the difference shows through. Thanks Neil From duncan.coutts at worc.ox.ac.uk Mon Aug 6 11:42:20 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Aug 6 11:33:15 2007 Subject: hacking cabal is too hard... In-Reply-To: <46B6E6F3.50808@gmail.com> References: <1186236565.5989.297.camel@localhost> <46B6E6F3.50808@gmail.com> Message-ID: <1186414940.25415.73.camel@localhost> On Mon, 2007-08-06 at 10:16 +0100, Simon Marlow wrote: > Duncan Coutts wrote: > > so what can we do about it? > > BTW, thanks for all the cleanup you did over the weekend, looks great. > > > Some barriers to entry: > > > > 1. reporting bugs requires logging in, many people still miss > > this. > > 2. bug reports get ignored (which is disheartening to users) > > because... > > 3. bug reports do not get reported to this list (like ghc ones get > > reported to the ghc-bugs list). This also means we get no public > > discussion going on most bugs, and the people who finally close > > bugs get no public recognition. > > The Trac configuration is set to auto CC this list with bug updates, but > the mailing list config needs to be updated to allow them through. Isaac > is the only one with admin permissions on the list at the moment, should we > add more people? Volunteers? I'm a moderator too at the moment, however the list is subscriber only so I only get notified about over-long posts etc. It was previously open but moderated and we got a huge amount of spam. > > 4. there is no cabal hacking guide, a short guide to the source > > code and style would help (eg explaining the main environments > > functions operate in, ie BuildInfo, LocalBuildInfo). Simple > > things like adding fields, commands or new flags. Thomas has offered to write a HACKING file. > > 5. it's not clear if it's possible to set up a local hackage > > servers to help test & hack on the hackage web code. > > 6. darcs sending patches get rejected by default since the > > cabal-devel list is subscriber only. > > Again, this is a mailing-list setup issue. cabal-devel should do the same > as cvs-ghc, and moderate by default (but someone needs to do the moderation). How does cvs-ghc deal with this? Does it go via a spam filter first before the moderator? And can the mailman white-list people so on their first post they can be cleared by the moderator to post from then on (without the person having to subscribe)? > > Probably more things. > > > > People often complain that the internal Cabal code is hard to > > understand, which is partly true though it's also related to point 4. > > ...and I think a lot can be done to improve things incrementally. Yes. > There are abstractions that are not consistently used (eg. Program, but it > sounds like you've improved things here), and missing abstractions > (compiler-specific stuff is not sufficiently abstracted). There are > over-complex abstractions: e.g. hooks. There are not-very abstractions: > the "simple" build system is wired-in when it was originally intended to be > layered on top of the basic infrastructure. I'm not sure whether we should > abandon this layering or try to do it properly. Yes, there's more work to do in improving the Program, PreProcessor and Compiler abstractions. > All this has arisen because Cabal has been hacked on by a wide range of > people, few of whom really took an interest in the design of the system as > a whole. Mostly we were trying to get the job done and make Cabal do what > we needed, which to a large extent it does. Aye. Cabal/Hackage is fantastically successful, despite the amount we grumble about it's shortcomings. > But this is fertile ground for hackers who enjoy cleaning things up and > refactoring... Certainly. How to recruit such people... I might try and do a 5-min status report at AngloHaskell. "Cabal needs you" or something :-) Duncan From pgavin at gmail.com Mon Aug 6 12:52:21 2007 From: pgavin at gmail.com (Peter Gavin) Date: Mon Aug 6 12:44:24 2007 Subject: hacking cabal is too hard... In-Reply-To: <1186414940.25415.73.camel@localhost> References: <1186236565.5989.297.camel@localhost> <46B6E6F3.50808@gmail.com> <1186414940.25415.73.camel@localhost> Message-ID: <37df87420708060952w30a1032h12feec9ce69d5cc9@mail.gmail.com> On 8/6/07, Duncan Coutts wrote: > Cabal/Hackage is fantastically successful, despite the amount we grumble > about it's shortcomings. > > > But this is fertile ground for hackers who enjoy cleaning things up and > > refactoring... > > Certainly. How to recruit such people... > > I might try and do a 5-min status report at AngloHaskell. > "Cabal needs you" or something :-) Some time ago Duncan and I briefly discussed a few things that I could do with Cabal. I forget exactly what they were now, but it had to do with getting Gtk2HS working better with it (or at all, even). I think I got sidetracked by school and other code I've been working on for Gtk2HS, so I never got around to it. I'm interested in helping you guys, but I suppose I should look at the Cabal code some more. One thing that Cabal seems to need is a flexible source code dependency resolution system. I think I'd like to hack something out in that area. Pete From ijones at syntaxpolice.org Mon Aug 6 13:00:43 2007 From: ijones at syntaxpolice.org (Isaac Potoczny-Jones) Date: Mon Aug 6 14:21:17 2007 Subject: hacking cabal is too hard... In-Reply-To: <1186414940.25415.73.camel@localhost> References: <1186236565.5989.297.camel@localhost> <46B6E6F3.50808@gmail.com> <1186414940.25415.73.camel@localhost> Message-ID: <46B753BB.5020202@syntaxpolice.org> Duncan Coutts wrote: > On Mon, 2007-08-06 at 10:16 +0100, Simon Marlow wrote: >> Duncan Coutts wrote: >>> so what can we do about it? >> BTW, thanks for all the cleanup you did over the weekend, looks great. >> >>> Some barriers to entry: Out of the 6 (very insightful) barriers to entry you mention, I note that items 1, 2, 3, and 6 all have their root cause in spam problems. Trac got overwhelmed by spam when it was more open, as did the moderation section of the mailing list, as you noted. It's really depressing. Maybe there are some tools out there that could help? >>> 1. reporting bugs requires logging in, many people still miss >>> this. >>> 2. bug reports get ignored (which is disheartening to users) >>> because... >>> 3. bug reports do not get reported to this list (like ghc ones get >>> reported to the ghc-bugs list). This also means we get no public >>> discussion going on most bugs, and the people who finally close >>> bugs get no public recognition. >> The Trac configuration is set to auto CC this list with bug updates, but >> the mailing list config needs to be updated to allow them through. Isaac >> is the only one with admin permissions on the list at the moment, should we >> add more people? Volunteers? I believe Duncan has all the rights on the list that I have, as he mentions and I'd be happy to add more volunteers. > I'm a moderator too at the moment, however the list is subscriber only > so I only get notified about over-long posts etc. It was previously open > but moderated and we got a huge amount of spam. :( >>> 4. there is no cabal hacking guide, a short guide to the source >>> code and style would help (eg explaining the main environments >>> functions operate in, ie BuildInfo, LocalBuildInfo). Simple >>> things like adding fields, commands or new flags. > > Thomas has offered to write a HACKING file. That's really great, thanks, Thomas! I'd be glad to proof it and help. >>> 5. it's not clear if it's possible to set up a local hackage >>> servers to help test & hack on the hackage web code. >>> 6. darcs sending patches get rejected by default since the >>> cabal-devel list is subscriber only. >> Again, this is a mailing-list setup issue. cabal-devel should do the same >> as cvs-ghc, and moderate by default (but someone needs to do the moderation). > > How does cvs-ghc deal with this? Does it go via a spam filter first > before the moderator? And can the mailman white-list people so on their > first post they can be cleared by the moderator to post from then on > (without the person having to subscribe)? > >>> Probably more things. >>> >>> People often complain that the internal Cabal code is hard to >>> understand, which is partly true though it's also related to point 4. >> ...and I think a lot can be done to improve things incrementally. (Snip. This is interesting when compared to this point:) >> All this has arisen because Cabal has been hacked on by a wide range of >> people, few of whom really took an interest in the design of the system as >> a whole. Mostly we were trying to get the job done and make Cabal do what >> we needed, which to a large extent it does. Although I hear that people do complain, I think it's very telling that Cabal has had so many contributers. Very few Haskell libraries that I can think of have had as many contributers as Cabal has. And please remember that to some extent, there's always going to be complaining when reading someone else's code. I'm not saying that there isn't room for improvement, there is definitely room for improvement. > Aye. > > Cabal/Hackage is fantastically successful, despite the amount we grumble > about it's shortcomings. > >> But this is fertile ground for hackers who enjoy cleaning things up and >> refactoring... > > Certainly. How to recruit such people... > > I might try and do a 5-min status report at AngloHaskell. > "Cabal needs you" or something :-) That would be great. peace, isaac From nominolo at googlemail.com Mon Aug 6 20:03:26 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Aug 6 19:55:30 2007 Subject: darcs patch: Split up make target for documentation g... (and 6 more) Message-ID: <46b7b6ce.270c360a.1403.ffffa95d@mx.google.com> Fri Aug 3 22:05:33 CEST 2007 Thomas Schilling * Split up make target for documentation generation. Allows to build the user's guide separately from the Haddock documentation. Tue Aug 7 01:46:10 CEST 2007 Thomas Schilling * Add -cpp option so it works with ghc, and fix import. Tue Aug 7 01:47:07 CEST 2007 Thomas Schilling * Allow querying for the wildcard version range. Tue Aug 7 01:51:31 CEST 2007 Thomas Schilling * Warn if no Cabal-version field is specified, but new syntax is used. This isn't quite exact. Ideally, we'd like to have something like isEmptyRange (specified-range && >= 1.2) but implementing isEmptyRange is non-trivial, so we'll go with this imperfect solution until we need that feature elsewhere. Tue Aug 7 01:54:04 CEST 2007 Thomas Schilling * No longer fail to parse packages without any library or executable sections. Issue a warning instead. (The previous error message "Unexpected end of file" was not very helpful.) Tue Aug 7 01:56:44 CEST 2007 Thomas Schilling * Cosmetic cleanup (fix line length) Tue Aug 7 02:01:55 CEST 2007 Thomas Schilling * Re-enable and update unit tests. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 35239 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070806/bb61889a/attachment-0001.bin From eivuokko at gmail.com Tue Aug 7 08:55:27 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Tue Aug 7 08:44:54 2007 Subject: Call for testers: cabal2wix 0.1.0 Message-ID: <46B86BBF.8020509@gmail.com> Hi, I have got first phase of cabal2wix done, it works for me, on my machine. I'm calling it 0.1.0. ;-) This is not a public release, just call for some help - if you have Windows and ghc 6.6.1, please consider trying out my MSIs, and let me know your experience. Some MSIs I built : http://tametea.dyndns.org/~eivuokko/tmp-msi/ * All MSI that are generated require Administrative rights, we need a plan where to put files for user-only installation. cabal2wix doesn't generate admin-specific code, but writing to default target, Program Files, requires admin rights. * There is no licenses included. I am not sure why Cabal doesn't install license files, but it doesn't, and cabal2wix doesn't either. * I have only tested these in Windows Vista, with GHC 6.6.1 packaged from Neil's installer scripts. * I didn't include docs on MSIs I built. Current features * Supports GHC, only 6.6.1 tested. * Supports executables, libraries and combination packages. (But only single-executable and library-only packages have been tested at all.) * Register library on install, unregisters on remove. * Can pack two or more cabal packages into one installer, registers each library on their own. darcs repo at: http://tametea.dyndns.org/~eivuokko/darcs/cabal2wix/ Building cabal2wix requires: * Default installation of ghc 6.6.1; base, filepath, cabal and directory. * Windows (misuse of filepath's ) Using requires: * Wix tools 3 * Packages buildable with cabal cabal2wix uses. Quick usage info: Setup configure Setup build Setup copy --destdir=dist\cabal2wix cabal2wix . -o dist\foo.wxs candle dist\foo.wxs -out dist\foo.wixobj light dist\foo.wixobj -out foo.msi Darcs repo has scripts\build-msi.bat, which semi-automates using tar,gzip,cabal,cabal2wix and wix 3. Thanks, Esa From eivuokko at gmail.com Tue Aug 7 09:22:34 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Tue Aug 7 09:14:35 2007 Subject: Developing cabal2wix - building Windows installers automatically In-Reply-To: <1186406803.25415.52.camel@localhost> References: <46B649A1.3000604@gmail.com> <1186406803.25415.52.camel@localhost> Message-ID: Hi, Sorry for slow reply, I tried to get cabalw2wix to state where it somehow works, so that I can distill the issues further. Unfortunately, that didn't help ;-) On 8/6/07, Duncan Coutts wrote: > On Mon, 2007-08-06 at 01:05 +0300, Esa Ilari Vuokko wrote: > > Issue 2: > > setup copy --destdir=foo is confusing in Windows. If my prefix is > > c:\Program Files (like it is if I run configure without options), > > the directory structure after copy is foo\Program Files - ie. unsuable > > locally because drive letter is missing, > > It's not clear that's true, if you copy the files in foo\Program Files\ > to C:\Program Files\ and register the package with ghc-pkg then it > should work fine. Yeah, but unlike unix, information is lost, and some of it is system dependent. Hence setup copy dist feel so very wrong in Windows. > > and unusable at remote > > locations, because Program Files is not localized. > > I'd like not to use all possible directory flags at configure time, > > because it is impossible to know how different packages react to them. > > I'm not sure why you say that; what they mean does not vary between > packages. I think setting the prefix and other directory flags should be > fine. If that's a rule for packages, I'll go with it. There is no such guarantee in Setup script. It also forces me to duplicate Cabal's logic on directory structure. > Since you want a relocatable package you do want to set prefix as ".". > As you said, some of the other bits are not relative to prefix on > windows, like the docs. So that's a problem. Yeah. Annoyance really. > > Suggestion: Make copy-hook unable to copy random files on their own, > > this way there could be setup copy --list-links, which would be > > nicer, IMHO. As the list could also differentiate between different > > types of files. Profiling lib, shared libs (dev and end-user > > installer in one.) > > I don't think it's a problem that cabal doesn't support this since it's > easy to generate an install image by copying into a temp dir. This is > the way most other build systems work (both unix and windows ones). All > you'd be saving is one bunch of file copies which is really pretty > cheap. Space is not my concern at all in this. It's the akwardness. setup copy clearly works because that's how unix files are typically organised. It typically seems clunky from Windows perspective. I'd also really like to know what each files does. Are they executables, libraries (and what kind!), interface file, etc. > > Issue 3: > > Currently cabal2wix reads dist\setup-config to find out package and > > compiler information. This is pretty stupid, as LocalBuildInfo > > structure might not be that stable, and cabal2wix can only guarantee > You an do that by calling functions in the Simple build system. Yes. I use read instance provided for LocalBuildInfo. It still will break if setup is built against cabal that has changed LocalBuildInfo structure AFAICT. Best regards, Esa From duncan.coutts at worc.ox.ac.uk Tue Aug 7 10:15:12 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Aug 7 10:06:03 2007 Subject: Developing cabal2wix - building Windows installers automatically In-Reply-To: References: <46B649A1.3000604@gmail.com> <1186406803.25415.52.camel@localhost> Message-ID: <1186496112.29254.24.camel@localhost> On Tue, 2007-08-07 at 16:22 +0300, Esa Ilari Vuokko wrote: > On 8/6/07, Duncan Coutts wrote: > > On Mon, 2007-08-06 at 01:05 +0300, Esa Ilari Vuokko wrote: > > > Issue 2: > > > setup copy --destdir=foo is confusing in Windows. If my prefix is > > > c:\Program Files (like it is if I run configure without options), > > > the directory structure after copy is foo\Program Files - ie. unsuable > > > locally because drive letter is missing, > > > > It's not clear that's true, if you copy the files in foo\Program Files\ > > to C:\Program Files\ and register the package with ghc-pkg then it > > should work fine. > > Yeah, but unlike unix, information is lost, and some of it is system > dependent. Hence setup copy dist feel so very wrong in Windows. I don't really understand this. Sure having a Program File prefix in your image directory is useless, so you want --prefix=. to get no extra prefix. But the concept of an install image is not at all useless. That's what all build systems give you, on windows or other systems. I've worked with windows installers before and the modus operandi is to start from an install image generated by the build system. That's what setup copy is for - for generating an install image. > > > and unusable at remote > > > locations, because Program Files is not localized. > > > I'd like not to use all possible directory flags at configure time, > > > because it is impossible to know how different packages react to them. > > > > I'm not sure why you say that; what they mean does not vary between > > packages. I think setting the prefix and other directory flags should be > > fine. > > If that's a rule for packages, I'll go with it. There is no such guarantee > in Setup script. If they're using the Simple build system (and almost all packages do) then you know that the directory flags to the same thing. > It also forces me to duplicate Cabal's logic on directory structure. I don't understand this. > > > Suggestion: Make copy-hook unable to copy random files on their own, > > > this way there could be setup copy --list-links, which would be > > > nicer, IMHO. As the list could also differentiate between different > > > types of files. Profiling lib, shared libs (dev and end-user > > > installer in one.) > > > > I don't think it's a problem that cabal doesn't support this since it's > > easy to generate an install image by copying into a temp dir. This is > > the way most other build systems work (both unix and windows ones). All > > you'd be saving is one bunch of file copies which is really pretty > > cheap. > > Space is not my concern at all in this. It's the akwardness. setup copy > clearly works because that's how unix files are typically organised. > It typically seems clunky from Windows perspective. If the install image is not laid out to your liking then it can be modified by overriding the various directory flags in the configure step. It may well be that these defaults are not yet right for windows or that there is insufficient flexibility in being able to modify the directories for particular kinds of files. Those are things we can fix. > I'd also really like to know what each files does. Are they executables, > libraries (and what kind!), interface file, etc. The way cabal (and other build systems) deal with this is that instead of identifying what each file is, they allow you to specify where various kinds of files should go. At the moment that's not sufficiently fine grained even for unix systems (eg we'd like to set docs independently from data files). You may also need more fine grained distinctions for Windows. Tell us what distinctions you need to make that you can't make at the moment, or better, tell us what you expect the install image to look like. > > You an do that by calling functions in the Simple build system. > > Yes. I use read instance provided for LocalBuildInfo. > > It still will break if setup is built against cabal that has changed > LocalBuildInfo structure AFAICT. Yes. This will happen frequently. Hmm, for packages that don't need hooks you could do the whole build using the cabal api and you'd have no problems, but for ones that use Setup.hs it's harder. Duncan From nominolo at googlemail.com Tue Aug 7 12:25:22 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue Aug 7 12:17:25 2007 Subject: darcs patch: Fix translation of deprecated fields. A... (and 2 more) Message-ID: <46b89cf2.1d0c360a.0726.ffffdd27@mx.google.com> Tue Aug 7 18:18:37 CEST 2007 Thomas Schilling * Fix translation of deprecated fields. Add test case. Tue Aug 7 18:20:01 CEST 2007 Thomas Schilling * Fix error message. Tue Aug 7 18:20:23 CEST 2007 Thomas Schilling * Add a little documentation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 22745 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070807/2ea56a3c/attachment-0001.bin From duncan.coutts at worc.ox.ac.uk Tue Aug 7 16:33:16 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Aug 7 16:24:05 2007 Subject: reason for both --libdir and --libsubdir ? Message-ID: <1186518796.29254.38.camel@localhost> I am trying to understand the reason we have so many --dir flags to configure. I'd prefer to remove what appear to be duplicates and add some more dir overrides for specific file types (like docs). We currently have: --libdir= and --libsubdir= --datadir= and --datasubdir= in each case the subdir flavour is an extra directory underneath the main dir which defaults to the package id. Seems to me that we can get rid of the subdir stuff because you can say: --libdir='/foo/bar/$pkgid/$compiler' Indeed this already works. So can we deprecate the subdir variants and tell people to just use these vars? The only thing the subdir thing was for is to be able to adjust the libdir while still getting the pkgid and compiler components generically and we can do that more flexibly with vars. Duncan From simonmarhaskell at gmail.com Wed Aug 8 04:19:04 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Aug 8 04:11:11 2007 Subject: Developing cabal2wix - building Windows installers automatically In-Reply-To: <46B649A1.3000604@gmail.com> References: <46B649A1.3000604@gmail.com> Message-ID: <46B97C78.1010804@gmail.com> Esa Ilari Vuokko wrote: > Hi, > > I decided to try to build a cabal -> wix converter, cabal2wix, to make > it easier to generate Windows installers for cabal-packages. My main > target is ghc-compiled libraries. There are few issues I've ran into > and I'd appreciate any comments on them. > > I'll try to publish the darcs repo somewhere if there's interest. > > Some of the issues are gray, as I don't understand all the details > myself, and reading Cabal's code isn't very enlightening. > > Issue 1: > Cabal puts (at least) docs under Program Files\Common Files - this > separates docs from other parts of the program by logical placing, Not quite true: for an executable, on Windows, docs currently go by default into $prefix\Haskell\$pkgid. See: http://www.haskell.org/ghc/docs/latest/html/Cabal/builders.html#setup-configure-paths For a library, data files go in C:\Program Files\Common Files\$pkgid. There's a very good reason for this: a library cannot discover its installation location like an executable can, because it could be linked in to an executable anywhere on the system. Hence if a library needs access to auxiliary data files, they better be in a fixed place in the filesystem. A library with data files cannot be fully relocatable at install-time. However, we do need to change where docs go (they don't have to go in $datadir, and they can be relocated at install-time). Cheers, Simon From simonmarhaskell at gmail.com Wed Aug 8 04:22:08 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Aug 8 04:14:16 2007 Subject: reason for both --libdir and --libsubdir ? In-Reply-To: <1186518796.29254.38.camel@localhost> References: <1186518796.29254.38.camel@localhost> Message-ID: <46B97D30.9000009@gmail.com> Duncan Coutts wrote: > I am trying to understand the reason we have so many --dir flags to > configure. I'd prefer to remove what appear to be duplicates and add > some more dir overrides for specific file types (like docs). > > We currently have: > > --libdir= and --libsubdir= > --datadir= and --datasubdir= > > in each case the subdir flavour is an extra directory underneath the > main dir which defaults to the package id. Seems to me that we can get > rid of the subdir stuff because you can say: > > --libdir='/foo/bar/$pkgid/$compiler' > > Indeed this already works. So can we deprecate the subdir variants and > tell people to just use these vars? > > The only thing the subdir thing was for is to be able to adjust the > libdir while still getting the pkgid and compiler components generically > and we can do that more flexibly with vars. Hmm, I remember going through several iterations of the design here before ending up with --libsubdir. I can't remember all the rationale now (darn, wish I'd written it down somehwere). Did you check the mailing list archives? Cheers, Simon From eivuokko at gmail.com Wed Aug 8 05:18:04 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Wed Aug 8 05:07:28 2007 Subject: Developing cabal2wix - building Windows installers automatically In-Reply-To: <46B97C78.1010804@gmail.com> References: <46B649A1.3000604@gmail.com> <46B97C78.1010804@gmail.com> Message-ID: <46B98A4C.1020705@gmail.com> Simon Marlow wrote: > Esa Ilari Vuokko wrote: >> Issue 1: >> Cabal puts (at least) docs under Program Files\Common Files - this >> separates docs from other parts of the program by logical placing, > > Not quite true: for an executable, on Windows, docs currently go by > default into $prefix\Haskell\$pkgid. See: > >http://www.haskell.org/ghc/docs/latest/html/Cabal/builders.html#setup-configure-paths Yes. I should have said library docs. > For a library, data files go in C:\Program Files\Common Files\$pkgid. > There's a very good reason for this: a library cannot discover its > installation location like an executable can, because it could be linked > in to an executable anywhere on the system. Hence if a library needs > access to auxiliary data files, they better be in a fixed place in the > filesystem. A library with data files cannot be fully relocatable at > install-time. This might be some unix trick, but in Windows you can at least * Use resource strings * Use registry And indeed, if that's the purpose, Common Files is pretty much the right directory. But, this is mainly for *widespread* libraries. In general it is much better that the application does the installing of library's data files and then tells library where they are. I don't really care, I think. Libraries that are not prepared for relocation are not ready for publishing in Windows, IMHO. > However, we do need to change where docs go (they don't have to go in > $datadir, and they can be relocated at install-time). Assuming docs are haddock generated, aren't they actually pretty much fixed because of links? Best regards, Esa From duncan.coutts at worc.ox.ac.uk Wed Aug 8 07:06:11 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 8 06:56:57 2007 Subject: reason for both --libdir and --libsubdir ? In-Reply-To: <46B97D30.9000009@gmail.com> References: <1186518796.29254.38.camel@localhost> <46B97D30.9000009@gmail.com> Message-ID: <1186571171.12043.16.camel@localhost> On Wed, 2007-08-08 at 09:22 +0100, Simon Marlow wrote: > Duncan Coutts wrote: > > I am trying to understand the reason we have so many --dir flags to > > configure. I'd prefer to remove what appear to be duplicates and add > > some more dir overrides for specific file types (like docs). > > > > We currently have: > > > > --libdir= and --libsubdir= > > --datadir= and --datasubdir= > Hmm, I remember going through several iterations of the design here before > ending up with --libsubdir. I can't remember all the rationale now (darn, > wish I'd written it down somehwere). Did you check the mailing list archives? Yes, looking back at some patch descriptions and the thread on the libraries list from Oct 2005 titled: "Cabal: bindir/libdir/datadir" the rationale becomes clearer. So the split between dir and subdir is for compatibility with autoconf, that is it allows users to say just --libdir=/usr/lib64 like they would with autoconf and end up with /usr/lib64/$pkgid/$compiler. What I was really trying to do is see if we can simplify or clarify the install paths code a bit since three people have tried and failed to add a --docdir flag thats separate from the --datadir. So I conclude that the current code is incomprehensible, perhaps because it's more complex than it needs to be or perhaps because the design just isn't documented in the code. What seems to make it complex is: * supporting prefix independence (on platforms that support it, like windows with ghc) * variable substitution * generating the Paths_pkg.hs module The logic for deciding if a package is actually relocatable isn't that obvious. It seems to be that it must be a program, not a lib and that it's bindir must be relative to $prefix. Additionally, on non-Windows, only hugs can do relocatable packages at the moment. Duncan From duncan.coutts at worc.ox.ac.uk Wed Aug 8 09:48:53 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Aug 8 09:39:40 2007 Subject: reason for both --libdir and --libsubdir ? In-Reply-To: <1186571171.12043.16.camel@localhost> References: <1186518796.29254.38.camel@localhost> <46B97D30.9000009@gmail.com> <1186571171.12043.16.camel@localhost> Message-ID: <1186580933.12043.24.camel@localhost> On Wed, 2007-08-08 at 12:06 +0100, Duncan Coutts wrote: > On Wed, 2007-08-08 at 09:22 +0100, Simon Marlow wrote: > > Duncan Coutts wrote: > > > I am trying to understand the reason we have so many --dir flags to > > > configure. I'd prefer to remove what appear to be duplicates and add > > > some more dir overrides for specific file types (like docs). > > > > > > We currently have: > > > > > > --libdir= and --libsubdir= > > > --datadir= and --datasubdir= > > > Hmm, I remember going through several iterations of the design here before > > ending up with --libsubdir. I can't remember all the rationale now (darn, > > wish I'd written it down somehwere). Did you check the mailing list archives? > > Yes, looking back at some patch descriptions and the thread on the > libraries list from Oct 2005 titled: "Cabal: bindir/libdir/datadir" the > rationale becomes clearer. > > So the split between dir and subdir is for compatibility with autoconf, > that is it allows users to say just --libdir=/usr/lib64 like they would > with autoconf and end up with /usr/lib64/$pkgid/$compiler. Just for reference here's autoconf's full list (it's big): --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] --bindir=DIR user executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIR program executables [EPREFIX/libexec] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/gtk2hs] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIR dvi documentation [DOCDIR] --pdfdir=DIR pdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR] See also: http://www.gnu.org/software/autoconf/manual/html_node/Installation-Directory-Variables.html#Installation-Directory-Variables http://www.gnu.org/software/autoconf/manual/standards/Directory-Variables.html#Directory-Variables They have some historical cruft we can ignore, like the --datarootdir and --oldincludedir. Note that the default autoconf docdir includes the package name. Additionally, automake supports installing files into any of these with an additional packagename subdir. From simonmarhaskell at gmail.com Wed Aug 8 11:19:29 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Aug 8 11:11:31 2007 Subject: Broken head In-Reply-To: <46B7BFF1.2060607@cse.unsw.edu.au> References: <46B68B04.9000202@cse.unsw.edu.au> <46B6E051.4010107@gmail.com> <46B6EB40.7060304@cse.unsw.edu.au> <1186395419.25415.14.camel@localhost> <46B7BFF1.2060607@cse.unsw.edu.au> Message-ID: <46B9DF01.1070009@gmail.com> Manuel M T Chakravarty wrote: > An automated system would be cool, but it'd require some effort to set > up. In the meantime, we should probably go with SimonM's proposal and > just make GHC use a subset-branch of the main Cabal repo. Pulling > changes over into GHC's Cabal branch would be a manual process, which > would involve running validate. Especially, if, as you wrote, you guys > are currently looking at breaking changes, that would be fairly urgent. > I'd rather not have another round of the GHC build breaking every week. I've just made GHC's Cabal into a branch. The main Cabal repo is http://darcs.haskell.org/cabal and GHC's branch is http://darcs.haskell.org/packages/Cabal (the latter used to be a symbolic link to the former, now they're separate repos). Can Cabal developers check that they're using the main Cabal repo when pushing, please? Cheers, Simon From magnus at smartelectronix.com Wed Aug 8 17:03:53 2007 From: magnus at smartelectronix.com (Magnus Jonsson) Date: Wed Aug 8 16:55:49 2007 Subject: Patch to fix parsing of ghc --supported-languages Message-ID: Extensions do not work with ghc 6.7. This patch fixes it: http://magnus.smartelectronix.com/temp/cabal-fix.darcs-patch Duncan knows what this is. Cheers, Magnus Jonsson From eivuokko at gmail.com Wed Aug 8 19:26:55 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Wed Aug 8 19:16:16 2007 Subject: ghc-pkg and quoting on haddock-related fields Message-ID: <46BA513F.7010401@gmail.com> Hi, I think some recent change might have brought following problem up. installed-pkg-config has some fields escaped when they have spaces (or commas as Thomas showed me in irc.) The token is quoted using Prelude.Show. In case of haddock-interfaces, Cabal actually asks this information back when using haddock to generate docs. ghc-pkg doesn't touch the fields in any way. However, System.Process (or Cabal's own layer) adds quoting for parameters as well, which leads to haddock calling openBinaryFile with a FilePath that contains quotes - and dies horribly. This happens as a rule in Windows when generating docs for package that depends on package that has it's docs installed to a path with spaces on it. Normally ghc is installed to a path with no spaces on it, and these problems don't come up before installing few extra packages with Cabal. Is the right fix to make Cabal unquote the fields it receives from ghc-pkg, or is there some more complex problem lurking around? Best regards, Esa From igloo at earth.li Wed Aug 8 19:30:21 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Aug 8 19:22:20 2007 Subject: Todays breakage In-Reply-To: <46B90DDB.5000408@cse.unsw.edu.au> References: <46B90DDB.5000408@cse.unsw.edu.au> Message-ID: <20070808233021.GA6614@matrix.chaos.earth.li> On Wed, Aug 08, 2007 at 10:27:07AM +1000, Manuel M T Chakravarty wrote: > /opt/local/bin/ghc -H64m -Onot -fasm -istage1/utils > -istage1/basicTypes -istage1/types -istage1/hsSyn > -istage1/prelude -istage1/rename -istage1/typecheck > -istage1/deSugar -istage1/coreSyn -istage1/vectorise > -istage1/specialise -istage1/simplCore -istage1/stranal > -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main > -istage1/profiling -istage1/parser -istage1/cprAnalysis > -istage1/ndpFlatten -istage1/iface -istage1/cmm > -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics > -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp > -Rghc-timing -O -fasm -H16M '-#include "cutils.h"' -DUSING_COMPAT > -i../compat -ignore-package Cabal -c main/HeaderInfo.hs -o > stage1/main/HeaderInfo.o -ohi stage1/main/HeaderInfo.hi > > main/HeaderInfo.hs:189:19: Not in scope: `compilerLanguagesKnown' > > main/HeaderInfo.hs:190:19: Not in scope: `compilerLanguages' I've pushed some patches that make things better, but it still doesn't work for me. Building base gives Data/Generics.hs:28:1: lexical error at character 'i' and if I try with the build rule rather than the make rule (i.e. use Cabal proper rather than GHCMakefile) then I get : Could not find module `': Use -v to see a list of the files searched for. which -v3 shows is caused by GHC being passed ..., "-fasm","-v","","Data.Generics","Data.Generics.Aliases", ... Thanks Ian From magnus at smartelectronix.com Wed Aug 8 19:45:00 2007 From: magnus at smartelectronix.com (Magnus Jonsson) Date: Wed Aug 8 19:36:57 2007 Subject: Todays breakage In-Reply-To: <20070808233021.GA6614@matrix.chaos.earth.li> References: <46B90DDB.5000408@cse.unsw.edu.au> <20070808233021.GA6614@matrix.chaos.earth.li> Message-ID: This is caused by a bug in Cabal. I have submitted a patch to cabal-devel already which fixes this! Hopefully it will be accepted soon. On Thu, 9 Aug 2007, Ian Lynagh wrote: > Building base gives > > Data/Generics.hs:28:1: lexical error at character 'i' > > and if I try with the build rule rather than the make rule (i.e. use > Cabal proper rather than GHCMakefile) then I get > > : > Could not find module `': > Use -v to see a list of the files searched for. > > which -v3 shows is caused by GHC being passed > > ..., "-fasm","-v","","Data.Generics","Data.Generics.Aliases", ... > > > Thanks > Ian > > _______________________________________________ > Cvs-ghc mailing list > Cvs-ghc@haskell.org > http://www.haskell.org/mailman/listinfo/cvs-ghc > From igloo at earth.li Wed Aug 8 19:54:08 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Aug 8 19:46:05 2007 Subject: Broken head In-Reply-To: <46B9DF01.1070009@gmail.com> References: <46B68B04.9000202@cse.unsw.edu.au> <46B6E051.4010107@gmail.com> <46B6EB40.7060304@cse.unsw.edu.au> <1186395419.25415.14.camel@localhost> <46B7BFF1.2060607@cse.unsw.edu.au> <46B9DF01.1070009@gmail.com> Message-ID: <20070808235408.GA7017@matrix.chaos.earth.li> On Wed, Aug 08, 2007 at 04:19:29PM +0100, Simon Marlow wrote: > > I've just made GHC's Cabal into a branch. FWIW I think this is a mistake. It'll make changing Cabal as part of changes to the larger system harder, and increases the global amount of effort necessary. Also, I think Cabal patches would benefit from being checked with GHC's testsuite. I don't think that Duncan's argument that requiring validation of Cabal patches would hamper new developers is valid, as their patches will always be being applied by someone like Duncan, who could do the validation. Thanks Ian From eivuokko at gmail.com Thu Aug 9 00:18:22 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Thu Aug 9 00:08:34 2007 Subject: ghc-pkg and quoting on haddock-related fields In-Reply-To: <46BA513F.7010401@gmail.com> References: <46BA513F.7010401@gmail.com> Message-ID: <46BA958E.1000409@gmail.com> Esa Ilari Vuokko wrote: > Is the right fix to make Cabal unquote the fields it > receives from ghc-pkg, or is there some more complex > problem lurking around? Attached patch uses existing parsers to handle ghc-pkg output. It still ignores multiple values, as it used to before, as well. I have no idea if it's the right approach, but it fixes the immediate problem for me. Thu Aug 9 07:11:53 FLE Daylight Time 2007 Esa Ilari Vuokko * Use existing parsers to handle ghc-pkg field output Best regards, Esa -------------- next part -------------- New patches: [Use existing parsers to handle ghc-pkg field output Esa Ilari Vuokko **20070809041153] { hunk ./Distribution/Simple/Haddock.hs 50 +import Distribution.Compat.ReadP(readP_to_S) hunk ./Distribution/Simple/Haddock.hs 53 +import Distribution.ParseUtils(Field(..), readFields, parseCommaList, parseFilePathQ) hunk ./Distribution/Simple/Haddock.hs 62 -import Distribution.Simple.Utils (die, createDirectoryIfMissingVerbose, +import Distribution.Simple.Utils (die, warn, createDirectoryIfMissingVerbose, hunk ./Distribution/Simple/Haddock.hs 71 -import Control.Monad(liftM, when, unless) -import Data.Char ( isSpace ) +import Control.Monad(liftM, when, unless, join) hunk ./Distribution/Simple/Haddock.hs 138 - let trim = reverse . dropWhile isSpace . reverse . dropWhile isSpace hunk ./Distribution/Simple/Haddock.hs 141 - return $ trim $ dropWhile (not . isSpace) $ head $ lines s + case readFields s of + (ParseOk _ ((F _ _ fieldVal):_)) -> + return . join . join . take 1 . map fst . filter (null . snd) + . readP_to_S (parseCommaList parseFilePathQ) $ fieldVal + _ -> do + warn verbosity $ "Unrecognised output from haddock: " ++ s + return [] } Context: [Oops, fix deprecated Distribution.Extension module Duncan Coutts **20070807172125 it no longer exports the internal per-compiler extension to flags functions as they are no longer exist and the equivalents are internal. ] [remove unused local vars Duncan Coutts **20070807171235] [Add compilerExtensions field to Compiler and make each compiler fill it in Duncan Coutts **20070807170653 It's just a list of supported extensions and the corresponding compiler flags. For most compilers this is currently just a static list. For ghc 6.7 and above we query ghc to find the list of language extensions it supports. In each case the code has moved out into the compiler-specific modules and the core code treats it generically. The extensionsToFlags function has been split into two: extensionsToFlags which now returns the flags for the supported extensions and unsupportedExtensions which does what it says it does. This is because the two roles of the previous function were always used separately, never together. ] [Use String rather than importing a module just to misuse a String type alias Duncan Coutts **20070807170526] [Add a little documentation. Thomas Schilling **20070807162023] [Fix error message. Thomas Schilling **20070807162001] [Fix translation of deprecated fields. Add test case. Thomas Schilling **20070807161837] [Warn if no Cabal-version field is specified, but new syntax is used. Thomas Schilling **20070806235131 This isn't quite exact. Ideally, we'd like to have something like isEmptyRange (specified-range && >= 1.2) but implementing isEmptyRange is non-trivial, so we'll go with this imperfect solution until we need that feature elsewhere. ] [Re-enable and update unit tests. Thomas Schilling **20070807000155] [Cosmetic cleanup (fix line length) Thomas Schilling **20070806235644] [No longer fail to parse packages without any library or executable Thomas Schilling **20070806235404 sections. Issue a warning instead. (The previous error message "Unexpected end of file" was not very helpful.) ] [Allow querying for the wildcard version range. Thomas Schilling **20070806234707] [Split up make target for documentation generation. Allows to build Thomas Schilling **20070803200533 the user's guide separately from the Haddock documentation. ] [Remove more os-specific cppery Duncan Coutts **20070807115707 The only difference for this one was / vs \\ path separators ] [Ask the compiler what languages it supports, when possible Ian Lynagh **20070805171323] [Remove use of cpp in Distribution.System Duncan Coutts **20070807111837 base it off of the System.Info.os string rather than cpp defs ] [Make things build with ghc-6.6.x rather than just ghc HEAD Duncan Coutts **20070807111724 filepath-1.0 does not export dropDrive ] [Pattern match on an OS datatype rather than using ifdef everywhere Ian Lynagh **20070805130347] [Add StandaloneDeriving extension Ian Lynagh **20070804192416] [extensionToGHCFlag is now version dependent, and uses -XFoo flags for >=6.7 Ian Lynagh **20070804191833] [Add TypeFamilies extension Ian Lynagh **20070804184959] [Don't complain about AllRightsReserved licenses Duncan Coutts **20070804125110 That can be done in hackage when people try to upload. Fixes bug #127. ] [Add setup register --gen-pkg-config flag for distros that want that. Duncan Coutts **20070804115512 It generates the actual file to be passed to the compiler's package program. This is obviously compiler-specific. ] [Correct the location of the haddock dir in inplace registrations Duncan Coutts **20070804115428] [normalise the input and output file names when pre-processing Duncan Coutts **20070804013029 eg so we don't call cpp with ././src/blah -o ./dist/blah since those ././ can end up in error messages. ] [Put the generated haddock-prolog file under dist Duncan Coutts **20070804004848] [Try and simplify cleaning by always removing dist Duncan Coutts **20070804004643 so we don't have to individually track all the files we create we still have to delete a few files outside of the build dir sadly the configuration is still preserved if you specify --save-configure ] [Remove compilerBinaryName, use compilerId instead Duncan Coutts **20070804004524] [Move compiler-specific code for configurion into compiler modules Duncan Coutts **20070803213321 There's slightly more code overally but it's no longer incomprehensible because it's not all mixed together for all the different compilers. ] [Clean up rather un-sbstract use of Compiler in configure Duncan Coutts **20070803205901] [-Wall police Duncan Coutts **20070802194000] [Change Compiler's compilerVersion fild to compilerId Duncan Coutts **20070802193400 Of type PackageIdentifier rather than Version. ] [Remove Distribution.Simple.Configure.findProgram as it's no longer used Duncan Coutts **20070802194230] [Put the haddock and hscolour version numbers in the global ProgramConfiguration Duncan Coutts **20070802185614 We do this during the configure step and then later we don't have to run haddock & hscolour again to find out their version numbers. This also eliminates some annoying module interdependencies. Eventually the Program abstraction ought to include the ability for programs to discover their own version numbers so it can be done more modularly. ] [Alter version parse error message to make it clearer Duncan Coutts **20070802181620] [Add version field to Program and add findProgram(AndVersion) utilities Duncan Coutts **20070802172941 findProgram and findProgramAndVersion construct Program values The latter makes it easier to parse output of --version calls. The idea is that we should carry the version number along with the program if we know it, so we can later decide version-dependent args without having to do more IO to find the program version, eg see use_optP_P & haddockVersion. ] [Tidy some imports/exports Duncan Coutts **20070802003250] [Remove redundant configure flags, missed bits of previous refactoring. Duncan Coutts **20070802003154] [Make the Compiler abstraction use the Program abstraction Duncan Coutts **20070801205428 So out with compilerPath :: FilePath, in with compilerProg :: Program Similarly for compilerPkgTool. Lots of knock-on changes due to this, including converting many more uses of rawSystemExit to rawSystemProgram. ] [Simplify rawSystemProgram using programPath Duncan Coutts **20070801200247] [Add programPath :: Program -> FilePath Duncan Coutts **20070801200139 At the moment it's a partial function, but we should change that by having a distinction between an abstract program and a configured program. ] [Clean up cpphs/ghc -cpp preprocessor code Duncan Coutts **20070801135256 Now better separated and uses Program better. Also no longer needs internal lookupProgram' utils function. ] [Clean up calling of ar, make it use Program abstraction Duncan Coutts **20070801021526] [Make all the pre-processors use the Program abstraction Duncan Coutts **20070801021049] [Improve hangling of the title and prolog for haddock docs Duncan Coutts **20070804021538 Only include ": " in the title if it has a synopsis to use as subtitle Use the description as the prolog, or if that's empty we use the synopsis. Do the same for executables, fixing bug #142. ] [Less confusing haddock command output when there are no libs in the package Duncan Coutts **20070804013133 It says: > No documentation was generated as this package does not contain a library. > Perhaps you want to use the haddock command with the --executables flag. ] [Add message saying where haddock docs got put Duncan Coutts **20070804010016 And make the similar message for sdist respect the verbosity ] [Make the writing registration script message less silly Duncan Coutts **20070804002353] [Fix haddock markup for finalizePackageDescription Duncan Coutts **20070804001745] [Change error message for tabs used as indentation to something more Thomas Schilling **20070803213331 helpful. ] [Fix import path to HUnit. Thomas Schilling **20070803200829] [Fix printing of 'impl' checks. Thomas Schilling **20070803200622] [Disallow tabs .cabal files with new syntax Thomas Schilling **20070803181244] [Fix tab in Cabal.cabal. Thomas Schilling **20070803175701] [Add impl(...) conditional to configurations. Thomas Schilling **20070802010527 You can now use expressions like impl( ghc >= 6.6.1 ) in conditionals in .cabal files. ] [Add documentation for Cabal Configurations. Thomas Schilling **20070803125632] [Move the SetupWrapper module under Distribution.Simple Duncan Coutts **20070803012304 It's really a wrapper around the simple build system. ] [Cleanup. fix line length Thomas Schilling **20070801221329] [Fix name of flag in error message Duncan Coutts **20070802172141] [Add readVersion convenience function to Distribution.Version Duncan Coutts **20070802171703 So it's merely readVersion :: String -> Maybe Version Having to use readP_to_S parseVersion all over the place is annoying. ] [extraArgs should override args in command lines Duncan Coutts **20070801023042 besides, the order was inconsistent within the same function between the UserSpecified and FoundOnSystem cases. ] [FIX compilation with GHC 6.2.x Simon Marlow **20070801095523] [Move the haddock code out into it's own module Duncan Coutts **20070731183410 It removes about 250 loc from Distribution.Simple ] [-Wall police Duncan Coutts **20070731173626] [Fix order of warnings. Thomas Schilling **20070730225311] [Add line numbers to unknown fields error message. Thomas Schilling **20070730225256] [Display a more helpful error message, when unknown fields are Thomas Schilling **20070730224026 noticed. ] [Fix self-compile warnings. Thomas Schilling **20070730220537] [Fix haddock markup Ian Lynagh **20070729233545 I haven't checked that it looks right, but it is now accepted by haddock. ] [Pass ghc -package flags when using it as a C compiler in GHCMakefile Ian Lynagh **20070729152803 This means we get the CPP include directories included. ] [Add a missing case in updateCfg Ian Lynagh **20070729105910] [Resolve conflicts Ian Lynagh **20070729105854] [Fix conflicts. Fix for changed argument to 'preprocessSources'. Thomas Schilling **20070728223322] [Rename field. Thomas Schilling **20070728223102] [Change HUnit module path to Test.HUnit (the default now). Thomas Schilling **20070728221453] [Add note to 'clean' that it could be simpler, but for compatibility Thomas Schilling **20070728221342 reasons isn't (for now). ] [Let sdist command run the preprocessors itself. This way we don't Thomas Schilling **20070728221237 have to put stuff into the source tree. ] [Store resolved package description in local build info. Thomas Schilling **20070728221102 The clean and sdist commands need to use a flattened representation of the original description. Note the notes for flattenPackageDescription for some problems with this approach. ] [Export 'flattenPackageDescription'. Thomas Schilling **20070728215155] [Minor documentation fix. Thomas Schilling **20070728214859] [Modify test case. Thomas Schilling **20070728214825] [Add function 'flattenPackageDescription'. Thomas Schilling **20070728214746] [Avoid reporting the same missing dependecy twice. Thomas Schilling **20070728214645] [Add documentation Thomas Schilling **20070728214541] [Add documentation Thomas Schilling **20070728214444] [Add/Fix test cases Thomas Schilling **20070728214410] [Minor. Moved some code. Thomas Schilling **20070719222541] [Add function 'ignoreCondition'. Thomas Schilling **20070719222444] [Re-enable and extend test case. Thomas Schilling **20070719222341] [Filter duplicate dependencies. Thomas Schilling **20070719222233] [Adopt new CondTree data structure. Thomas Schilling **20070719125305 'finalizePackageDescription' now also takes dependencies of executables into account. ] [Change CondTree data structure to something more flexible. Thomas Schilling **20070719124655 This also requires some interface changes. ] [Add simpler representation of a .cabal file with conditions. Thomas Schilling **20070717203942] [Preprocessor output never gets written back to the source dir. Thomas Schilling **20070717174026 'preprocessSources' now gets an additional flag to determine whether to process all sources (for building) or only platform independent ones (for sdist). ] [Add resolved package description to 'LocalBuildInfo'. Thomas Schilling **20070716204325] [Fix removed import by importing a required accessor only. Thomas Schilling **20070716204238] [Add tags target to generate a tags file using 'hasktags'. (Unix only) Thomas Schilling **20070716203015] [Rename 'PreparedPackageDescription' to 'GenericPackageDescription' Thomas Schilling **20070716200427] [Remove unused dependency. Thomas Schilling **20070716200215] [Move configured_cabal to 'dist' directory. Thomas Schilling **20070716154146] [Bugfix by Ian Lynagh: Cabal can't have a Cabal-Version header; it breaks bootstrapping Thomas Schilling **20070716151535] [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] [Use the right output directory when building C sources for executables Duncan Coutts **20070726213309] [Use our own GetOpt if __GLASGOW_HASKELL__ >= 606 only Ian Lynagh **20070724213112 Used to be if __GLASGOW_HASKELL__ >= 604, but the 6.4 branch had a bug which looks likely to be the cause of GHC build failures we're seeing: - procNextOpt (NonOpt x) RequireOrder = ([],x:rest,us,[]) + procNextOpt (NonOpt x) RequireOrder = ([],x:rest,[],[]) ] [-Wall police Duncan Coutts **20070724172023] [Update user guide about haddock --css --hyperlink-source --hscolour-css Duncan Coutts **20070724160742 The haddock --css flag is new. The old --hscolour=[path] flag got split into two flags: --hyperlink-source and --hscolour-css=path ] [Remove a couple bits of unused code and imports Duncan Coutts **20070724110732] [use nhc-Options rather than deprecated nhc98-Options Duncan Coutts **20070724110703] [Hugs build: track change to install-includes Ross Paterson **20070724101816] [Rename --hscolour to --hyperlink-source and add haddock --css flag Duncan Coutts **20070723190026 So now --hyperlink-source controles wether or not we run hscolour and get haddock to link to the sources. The new flag --hscolour-css can be used to override the css file that hscolour uses. Also, the new flag --css can override the css file that haddock uses. ] [Merges from hscolour patch and make it work with haddock-0.8 Duncan Coutts **20070723180602 Some minor changes due to changes since the hscolour patch was written. Make it work with haddock-0.8 by using %{MODULE} rather than %{FILE} and generate output file names to match (ie not using the original file extension, just using the module name for the output file). ] [HsColour support Roberto Zunino **20070530194747 Integration of Cabal, HsColour, and Haddock. (Also fixes bug #102) ] [Remove ContextStack extension Ian Lynagh **20070709132341 Seems to be based on GHC's -fcontext-stack flag, which takes an integer argument. ] [Remove InlinePhase extension Ian Lynagh **20070708172919 As far as I can tell (a) The -finline-phase flag stopped actually being accepted by GHC sometime between GHC 4.08.2 and GHC 5.04.3 (b) It took an Int argument ] [Add KindSignatures extension Ian Lynagh **20070708120616] [Add the MagicHash extension Ian Lynagh **20070708111043] [TAG 2007-06-29 Ian Lynagh **20070629112545] Patch bundle hash: a608bac28167cbcb85c567a31d2736c22e249753 From simonmarhaskell at gmail.com Thu Aug 9 04:07:47 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Aug 9 03:59:47 2007 Subject: Broken head In-Reply-To: <20070808235408.GA7017@matrix.chaos.earth.li> References: <46B68B04.9000202@cse.unsw.edu.au> <46B6E051.4010107@gmail.com> <46B6EB40.7060304@cse.unsw.edu.au> <1186395419.25415.14.camel@localhost> <46B7BFF1.2060607@cse.unsw.edu.au> <46B9DF01.1070009@gmail.com> <20070808235408.GA7017@matrix.chaos.earth.li> Message-ID: <46BACB53.9070300@gmail.com> Ian Lynagh wrote: > On Wed, Aug 08, 2007 at 04:19:29PM +0100, Simon Marlow wrote: >> I've just made GHC's Cabal into a branch. > > FWIW I think this is a mistake. It'll make changing Cabal as part of > changes to the larger system harder, and increases the global amount of > effort necessary. > > Also, I think Cabal patches would benefit from being checked with GHC's > testsuite. > > I don't think that Duncan's argument that requiring validation of Cabal > patches would hamper new developers is valid, as their patches will > always be being applied by someone like Duncan, who could do the > validation. I'm not especially keen on having another branch either, but the alternative is that patches to Cabal must pass GHC's validate before being pushed, and that puts the burden on the Cabal developers to fix GHC and the core packages when breaking changes are made to Cabal - that doesn't seem right. OTOH it's true that the GHC build is a good testcase for Cabal (it looks like Cabal is broken right now, and testing with GHC would have discovered that). Duncan, any thoughts? Do you prefer the branch, or would you be happy to run GHC's validate before pushing to Cabal? This would affect people like Ross who push directly to Cabal too. Cheers, Simon From simonmarhaskell at gmail.com Thu Aug 9 04:49:14 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Aug 9 04:41:12 2007 Subject: Todays breakage In-Reply-To: <20070808233021.GA6614@matrix.chaos.earth.li> References: <46B90DDB.5000408@cse.unsw.edu.au> <20070808233021.GA6614@matrix.chaos.earth.li> Message-ID: <46BAD50A.2010306@gmail.com> Ian Lynagh wrote: > On Wed, Aug 08, 2007 at 10:27:07AM +1000, Manuel M T Chakravarty wrote: >> /opt/local/bin/ghc -H64m -Onot -fasm -istage1/utils >> -istage1/basicTypes -istage1/types -istage1/hsSyn >> -istage1/prelude -istage1/rename -istage1/typecheck >> -istage1/deSugar -istage1/coreSyn -istage1/vectorise >> -istage1/specialise -istage1/simplCore -istage1/stranal >> -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main >> -istage1/profiling -istage1/parser -istage1/cprAnalysis >> -istage1/ndpFlatten -istage1/iface -istage1/cmm >> -istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics >> -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp >> -Rghc-timing -O -fasm -H16M '-#include "cutils.h"' -DUSING_COMPAT >> -i../compat -ignore-package Cabal -c main/HeaderInfo.hs -o >> stage1/main/HeaderInfo.o -ohi stage1/main/HeaderInfo.hi >> >> main/HeaderInfo.hs:189:19: Not in scope: `compilerLanguagesKnown' >> >> main/HeaderInfo.hs:190:19: Not in scope: `compilerLanguages' > > I've pushed some patches that make things better, but it still doesn't > work for me. > > Building base gives > > Data/Generics.hs:28:1: lexical error at character 'i' > > and if I try with the build rule rather than the make rule (i.e. use > Cabal proper rather than GHCMakefile) then I get > > : > Could not find module `': > Use -v to see a list of the files searched for. > > which -v3 shows is caused by GHC being passed > > ..., "-fasm","-v","","Data.Generics","Data.Generics.Aliases", ... I'm validating a fix right now. Cheers, Simon From magnus at smartelectronix.com Thu Aug 9 05:25:12 2007 From: magnus at smartelectronix.com (Magnus Jonsson) Date: Thu Aug 9 05:17:07 2007 Subject: Todays breakage In-Reply-To: <46BAD50A.2010306@gmail.com> References: <46B90DDB.5000408@cse.unsw.edu.au> <20070808233021.GA6614@matrix.chaos.earth.li> <46BAD50A.2010306@gmail.com> Message-ID: It is already fixed if you pull the latest cabal (not the branch). On Thu, 9 Aug 2007, Simon Marlow wrote: >> I've pushed some patches that make things better, but it still doesn't >> work for me. >> >> Building base gives >> >> Data/Generics.hs:28:1: lexical error at character 'i' >> >> and if I try with the build rule rather than the make rule (i.e. use >> Cabal proper rather than GHCMakefile) then I get >> >> : >> Could not find module `': >> Use -v to see a list of the files searched for. >> >> which -v3 shows is caused by GHC being passed >> >> ..., "-fasm","-v","","Data.Generics","Data.Generics.Aliases", ... > > I'm validating a fix right now. > > Cheers, > Simon > _______________________________________________ > cabal-devel mailing list > cabal-devel@haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > From eivuokko at gmail.com Thu Aug 9 09:54:37 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Thu Aug 9 09:43:57 2007 Subject: Getting haddock docs links right Message-ID: <46BB1C9D.4090808@gmail.com> Yo, There appears to be big hole in how we handle haddock generated docs, with ghc, at least in Windows. I am very much not expert on this, so please let me know if any of this is wrong! I think the problem is that every stage on current infrastructure assumes they know where docs are, and are going to be. In a matter of fact, they do not. * haddock assumes * either absolute locations, or * docs bunched together. * Cabal just redirects the information from ghc-pkg and commandline. * Ghc build/install assumes docs are crammed into it's installation directory, but at least has $topdir functionality to defer decision making a bit. Here I have few situations that are currently broken, at least when using packages as generated by cabal+cabal2wix. * User install ghc in different location than c:\ghc\ghc-6.6.1 - all links to base and other bundled packages are broken. * User has different localisation or drive for Program Files than packager - all links to other non-ghc-bundled packages are wrong. (And when cabal2wix supports non-admin installs:) * User-installed packages - all links to user-installed packages are wrong. How can we solve this? * installing packages in common directory structure similar to docs bundled with ghc. (Cabal's --html-location can achieve this) * This directory structure contains no package versions?, so only one version of package can be installed (patch haddock). * non-admin packages cannot refer correctly to admin packages, as docs would be in different dirs (fix: copy files around as post-install step.) * No links from non-ghc-bundled packages to, well, anything. * Solves nothing, except no frustrating broken links - let them assume we can't do it. * Duncan suggested using html entities - it would require writing out small index at post-install. Anyone know if this is possible and reliable technique? * Reinstalling package in a different location might leave dependent packages with broken links. * Using a post-install step to rewrite links. * Seems fragile. * Installs require even more logic. * Writing a local web server that does all the correct uri mapping for user. * Rather heavy, and additional dependency. * Your idea here! Thanks, Esa From igloo at earth.li Thu Aug 9 10:08:08 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Aug 9 10:00:07 2007 Subject: Developing cabal2wix - building Windows installers automatically In-Reply-To: <46B97C78.1010804@gmail.com> References: <46B649A1.3000604@gmail.com> <46B97C78.1010804@gmail.com> Message-ID: <20070809140808.GA4179@matrix.chaos.earth.li> On Wed, Aug 08, 2007 at 09:19:04AM +0100, Simon Marlow wrote: > > For a library, data files go in C:\Program Files\Common Files\$pkgid. > There's a very good reason for this: a library cannot discover its > installation location like an executable can, because it could be linked in > to an executable anywhere on the system. Hence if a library needs access > to auxiliary data files, they better be in a fixed place in the filesystem. If a library needs auxiliary data files, how are they meant to get installed when someone makes a binary release of a program available? Thanks Ian From ross at soi.city.ac.uk Fri Aug 10 12:49:20 2007 From: ross at soi.city.ac.uk (ross@soi.city.ac.uk) Date: Fri Aug 10 12:41:11 2007 Subject: what is --scratchdir= for? In-Reply-To: <1186180797.5989.247.camel@localhost> References: <1186180797.5989.247.camel@localhost> Message-ID: <1186764560.46bc9710c2c26@fred.soi.city.ac.uk> Quoting Duncan Coutts : > It's not clear to me what the configure --scratchdir= option is for. It > seems to be only used by hugs for building and installing and it > defaults to dist/scratch. > > We don't allow any of the other locations under dist/scratch to be > overridden, probably because there's not much point in that. Why do we > need it for hugs? > > If we're going to have an option like this it should probably set the > location of the whole dist/ directory hierarchy. Though that has its own > problems since we'd need to have --scratchdir= as a global option to > each command since we put the saved config info into $dist/ . > > In the mean time, if we're keeping dist/ fixed then we can always just > rm -rf dist when doing a clean, fixing bug #92. If we allow the user to > override $dist then we'd have to be a bit more removing it since the > user could set it to some shared temp dir. Yes, --scratchdir is a hack for the Hugs build that allows it to build libraries that can be run inplace prior to installation. An option to move the whole of dist wouldn't be a replacement. I also think an option to move dist would introduce too many complications. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From eivuokko at gmail.com Fri Aug 10 16:10:51 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Fri Aug 10 16:02:40 2007 Subject: what is --scratchdir= for? In-Reply-To: <1186764560.46bc9710c2c26@fred.soi.city.ac.uk> References: <1186180797.5989.247.camel@localhost> <1186764560.46bc9710c2c26@fred.soi.city.ac.uk> Message-ID: On 8/10/07, ross@soi.city.ac.uk wrote: > I also think an option to move dist would introduce too many complications. Lack of such option, in my opinion, shows how immature Cabal is as a build tool. I'd use the option if it existed, even with the drawbacks. However, I agree this might be too much for now - there's more important things broken in Cabal, and there's not enough developers. Too bad adding the option is likely to only get harder as Cabal expands and gets more users who rely on current behavior. Best regards, Esa From marco-oweber at gmx.de Sat Aug 11 05:50:47 2007 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Aug 11 05:42:37 2007 Subject: weired exception ? Message-ID: <20070811095047.GB18563@gmx.de> when invoking runhaskell setup.hs copy I'm getting *** Exception: waitForProcess: does not exist (No child processes) When using ghc -make setup; ./setup ... the problem doesn't appear. Any idea what might causing this. Using runhaskell is much faster then compiling setup. When I have more time I'll try debugging this issue more in depth. Marc From eivuokko at gmail.com Sat Aug 11 09:05:35 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Sat Aug 11 08:54:48 2007 Subject: Few questions Message-ID: <46BDB41F.7070304@gmail.com> Hi, I have few more questions, I couldn't find answer on my own, even if they mostly seem silly :-) If there's resolutions requiring coding, I'll try to follow up with patches. * Are extended fields going to be part of public interface (HEAD Cabal doesn't warn for fields starting "x-")? * Could we document what's allowed format/character set for file specified by license-file? (cabal2wix needs to make rtf from the text to show it during install - I'd like to know if that's going to be sensibly possible.) * Is ghc-pkg supposed to handle license-file field? GHC documents it, referring to Cabal docs, but Cabal doesn't generate it for installed-pkg-config. (Maybe because license file is not installed?) * Are defaultMain-helpers supposed to turn relative paths from commandline into absolute ones? (I ran into this problem with Alex' Setup.lhs, which changes working directory for copying files.) Best regards, Esa From stefanor at cox.net Sat Aug 11 15:42:01 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Aug 11 15:33:48 2007 Subject: weired exception ? In-Reply-To: <20070811095047.GB18563@gmx.de> References: <20070811095047.GB18563@gmx.de> Message-ID: <20070811194201.GB3582@localhost.localdomain> On Sat, Aug 11, 2007 at 11:50:47AM +0200, Marc Weber wrote: > when invoking > runhaskell setup.hs copy > I'm getting > *** Exception: waitForProcess: does not exist (No child processes) > > When using ghc -make setup; ./setup ... > the problem doesn't appear. > > Any idea what might causing this. > > Using runhaskell is much faster then compiling setup. > > When I have more time I'll try debugging this issue more in depth. Sound like it might be connected to bug #945, which was closed only as cantreproduce... http://hackage.haskell.org/trac/ghc/ticket/945 Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/cabal-devel/attachme