August 2007 - cabal-devel

Re: Todays breakage
by Ian Lynagh 09 Aug '07

09 Aug '07

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 <command line>: 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

3 3

ghc-pkg and quoting on haddock-related fields
by Esa Ilari Vuokko 09 Aug '07

09 Aug '07

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

1 1

Patch to fix parsing of ghc --supported-languages
by Magnus Jonsson 08 Aug '07

08 Aug '07

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

1 0

reason for both --libdir and --libsubdir ?
by Duncan Coutts 08 Aug '07

08 Aug '07

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

2 3

darcs patch: Fix translation of deprecated fields. A... (and 2 more)
by Thomas Schilling 07 Aug '07

07 Aug '07

Tue Aug 7 18:18:37 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Fix translation of deprecated fields. Add test case. Tue Aug 7 18:20:01 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Fix error message. Tue Aug 7 18:20:23 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Add a little documentation.

1 0

Call for testers: cabal2wix 0.1.0
by Esa Ilari Vuokko 07 Aug '07

07 Aug '07

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

1 0

darcs patch: Split up make target for documentation g... (and 6 more)
by Thomas Schilling 06 Aug '07

06 Aug '07

Fri Aug 3 22:05:33 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * 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 <nominolo(a)gmail.com> * Add -cpp option so it works with ghc, and fix import. Tue Aug 7 01:47:07 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Allow querying for the wildcard version range. Tue Aug 7 01:51:31 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * 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 <nominolo(a)gmail.com> * 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 <nominolo(a)gmail.com> * Cosmetic cleanup (fix line length) Tue Aug 7 02:01:55 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Re-enable and update unit tests.

1 0

Hackage rocks
by Duncan Coutts 06 Aug '07

06 Aug '07

Yes indeed, Hackage rocks. Henning Günther wrote a Hackage -> Gentoo ebuild conversion tool for us and that allowed us to import more than 50 new packages into the Gentoo Haskell overlay. So we now have more than 150 packages available in the overlay, with a subset of 50 in the main Gentoo portage tree. This kind of productivity would have been impossible previously. So with that number of packages available we should be able to give a QA perspective. I've not checked exhaustively but here's my impression of common issues: * 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? * packages not building with later versions of dependent packages. Eg changes in what modules are re-exported by some mtl modules between mtl-1.0 and 1.0.1. * 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). Duncan

5 6

Re: Broken head
by Duncan Coutts 06 Aug '07

06 Aug '07

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

1 0

Re: Broken head
by Simon Marlow 06 Aug '07

06 Aug '07

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

1 0