June 2007 - cabal-devel

Converting Yhc to use Cabal
by Neil Mitchell 21 Jun '07

21 Jun '07

Hi, I'd like to convert Yhc to use Cabal. This presents several challenges: * We would like to depend on fps/base depending on compiler version. Configurations will allow this. * We have the library Yhc.Core in our tree which is developed in parallel with Yhc. What would be nice is to have a Yhc.Core library which we don't have to explicitly install each time. I guess having all the Yhc.Core files in both the library, and again in the program would work. * We'd ideally like multiple cabal files in one directory - for things like ycr2js, yhc, yhi etc. * Can Cabal compile C files? Can it do things like testing the size of int/long etc? * Is cabal-install ready for serious use? If so we would like to use this as our primary method of compilation. I suspect that it will not be possible to move entirely to Cabal initially - but perhaps Yhc can point out features that Cabal lacks. Thanks Neil

5 6

Testing Cabal
by Thomas Schilling 20 Jun '07

20 Jun '07

Now that I built my first (bogus) package that takes advantage of configurations I tried to run the test suite again, but I'm not sure what the intended output is. What's a bit strange is that my current version drops file ".configured_cabal" in the directory where Setup.lhs is, but I can't find that file anywhere (it currently isn't removed by the clean command.) Here's what I get: $ make tests mkdir -p dist/debug ghc --make -cpp -Wall -DHAVE_UNIX_PACKAGE -DDEBUG -odir dist/debug - hidir dist/debug -idist/debug/:src:tests/HUnit-1.0/src tests/ ModuleTest.hs -o moduleTest [ 1 of 39] Compiling HUnitLang ( tests/HUnit-1.0/src/ HUnitLang.lhs, dist/debug/HUnitLang.o ) -- snip -- [ 2 of 39] Compiling HUnitBase ( tests/HUnit-1.0/src/ HUnitBase.lhs, dist/debug/HUnitBase.o ) -- etc. -- [39 of 39] Compiling Main ( tests/ModuleTest.hs, dist/ debug/Main.o ) Linking moduleTest ... rm -f Distribution/*.o Distribution/*.hi rm -f Distribution/Compat/*.o Distribution/Compat/*.hi rm -f Distribution/PreProcess/*.o Distribution/PreProcess/*.hi rm -f Distribution/Simple/*.o Distribution/Simple/*.hi rm -f Language/Haskell/*.o Language/Haskell/*.hi rm -f darcs* out.build *~ semantic.cache* x*.html rm -f library-infrastructure--darcs.tar.gz rm -rf setup *.o *.hi moduleTest dist installed-pkg-config rm -f build-stamp rm -rf dist/hugs rm -f hunit-stamp hunitInstall-stamp cd tests/HUnit-1.0 && make clean rm -f setup a.out .setup-config register.sh unregister.sh out.build rm -rf ,tmp* dist find . -name "*.o" |xargs rm -f find . -name "*.hi" |xargs rm -f find . -name "*~" | xargs rm -f cd tests/A && make clean rm -f setup a.out .setup-config register.sh unregister.sh out.build rm -rf ,tmp* dist find . -name "*.o" |xargs rm -f find . -name "*.hi" |xargs rm -f find . -name "*~" | xargs rm -f cd tests/wash2hs && make clean rm -f setup a.out .setup-config register.sh unregister.sh out.build rm -rf ,tmp* dist find . -name "*.o" |xargs rm -f find . -name "*.hi" |xargs rm -f find . -name "*~" | xargs rm -f cd doc && make clean rm -fr *~ API users-guide Cabal.pdf Cabal.dvi semantic.cache cd tests/A && make clean rm -f setup a.out .setup-config register.sh unregister.sh out.build rm -rf ,tmp* dist find . -name "*.o" |xargs rm -f find . -name "*.hi" |xargs rm -f find . -name "*~" | xargs rm -f cd tests/HUnit-1.0 && make clean rm -f setup a.out .setup-config register.sh unregister.sh out.build rm -rf ,tmp* dist find . -name "*.o" |xargs rm -f find . -name "*.hi" |xargs rm -f find . -name "*~" | xargs rm -f cd tests/A && make ghc -cpp -DCABAL_VERSION=1,1,7 --make -i../.. Setup.lhs -o setup 2>out.build cd tests/HUnit-1.0 && make ghc -cpp -DCABAL_VERSION=1,1,7 --make -i../.. Setup.lhs -o setup 2>out.build $

2 1

Test Cases for Configurations
by Thomas Schilling 18 Jun '07

18 Jun '07

Hi, it's still a little work to do, but I think I'll be able to try and use Cabal configurations some time next week. Do you guys have any ideas what we could use as a good test case? The goal is to find out how well the current scheme applies to actual use cases (and if there are serious performance problems to await). / Thomas

7 18

HsColour integration (patch)
by Roberto Zunino 15 Jun '07

15 Jun '07

I am sending a patch[1] for integrating Cabal and HsColour + Haddock. Here is the result of running it on the base package: http://www.di.unipi.it/~zunino/tmp/base/index.html The above was generated by ./Setup configure ./Setup haddock --hscolour=hscolour.css Requirements: HsColour >=1.8, my hscolour.css file[2] (or your own, of course!), darcs Haddock + a link-breaking-bug fix (already sent) + any version bump (required: haddock > 0.8). Enjoy, Zun. [1] http://www.di.unipi.it/~zunino/tmp/cabal-hscolour-20070530 [2] http://www.di.unipi.it/~zunino/tmp/hscolour-emacs.css

3 4

setting up a chroot jail
by Sascha Böhme 15 Jun '07

15 Jun '07

Hello, although my question may be out of topic, I kindly ask for your help. I am working on the Google summer of code project to enhance the HackageDB website, especially by a tool to automatically generate Haddock documentation. For this to work, it is necessary to set up a chroot jail, in which packages are unpacked, configured and Haddock documentation is build. Some packages also need to be build, which could include running untrustable code. Up to now, I considered several ideas to set up a chroot jail, but they all do not fully satisfy my needs or I could not test them on my machine. Here are my proposals for setting up a chroot environment: 1) use a hand-written script 2) use makejail, jail, jailkit (or a similar tool) 3) use debootstrap 4) use dpkg to install necessary debian packages My distribution is gentoo, which is why I did not test 3). However, I thought that 4) is suitable, although it's very tedious. In fact, it seems to me like rewriting parts of debian installers. Option 1) is just not maintainable. Finally, 2) seems to be of use just for servers like ssh or ftp. I haven't tested it, but I doubt it will work in an environment with several different applications like ghc, haddock, cpphs, happy, ... Does anyone have an idea how to (automatically, maintainably) set up a chroot jail for this particular situation? I'm grateful for any help. Thanks, Sascha

4 3

Parsec as a Dependency?
by Thomas Schilling 13 Jun '07

13 Jun '07

Hi Caballers, now that .cabal files are getting a more complex syntax (due to configurations), I'd really like to use Parsec instead of lots of hand-written and hard to maintain parsing code. By getting rid of ReadP-based field parsing, we'd also get proper error messages for field values. At the Parsec homepage I says that it's now included by default in GHC, Hugs and NHC, so it'll most likely be present on any sufficiently recent system. What would be arguments against this proposal? / Thomas

5 8

Bugs and interface changes
by Ian Lynagh 07 Jun '07

07 Jun '07

Hi all, I've gone through the Cabal bugs and tried to make sure that those that mean interface changes are marked as high priority. Any of these that we can get done before the next round of releases will hopefully mean fewer headaches in the longrun. By the way, do bugs get automatically assigned to ijones? That doesn't seem very useful to me. Thanks Ian

2 1

#140 (Cabal doesn't allow doc/html/<package name> to be overridden)
by Ross Paterson 06 Jun '07

06 Jun '07

igloo writes: > Distribution.Simple.LocalBuildInfo uses > > haddockPref pkg_descr > = foldl1 (</>) [distPref, "doc", "html", pkgName (package pkg_descr)] > > and provides no way to override it. This should be a new field docdir > (or similar), and be overridable with a configure flag. haddockPref determines where the documentation is built; mkHaddockDir says where it is installed, currently $datadir/$datasubdir/doc/html/$pkg, where $datasubdir defaults to $pkgid. That default doesn't seem right in any case. Perhaps we want --docdir (defaulting to $prefix/share/doc on Unix and something else on Windows) --htmlsubdir (defaulting to $pkgid/html)

2 1

copy / register / --gen-script and --destdir
by Marc Weber 05 Jun '07

05 Jun '07

I can use ./setup copy --destdir to copy all hi files etc to some directory. But how do I register it then? Setting --prefix when using configure does'nt seem to adjust the register.sh using --gen-script I just can't add --destdir. What am I missing? Marc

3 4

Re: Cabal -extra-lib-dirs and -rpath, also framework-dirs
by Duncan Coutts 04 Jun '07

04 Jun '07

On Sun, 2007-06-03 at 15:48 -0700, Ashley Yakeley wrote: > 1. It seems entries on the extra-lib-dirs line in cabal (GHC 6.6) are > not passed to the linker with -rpath. Instead, you have to do that in > ld-options with "-Wl,-rpath -Wl,mylibdir". The trouble is this is not > portable, as the Darwin (Mac OS X) linker doesn't accept the -rpath > option and (I think) simply uses all -L directories for the runtime path > or some clever thing. > > I recommend that either extra-lib-dirs be passed as -rpath (as > appropriate for the platform), or a new field such as "extra-rpath-dirs" > be added. Ugg. This is somewhat a can of worms. For one thing it doesn't work on windows, but also it's not necessarily what one always wants. For example building on one machine and deploying on another, if there are specific paths baked into the libraries/executables that might be intended to be on the standard dynamic linker path on the target machine. I think this issue needs a fair bit of thought before we go and implement something. We should see what other systems do etc. > 2. Cabal doesn't recognise "framework-dirs" as a field name, even though > it shows up in "ghc-pkg describe". Yes, cabal does not currently support that field. It probably should. The format used by ghc-pkg is quite similar to the cabal format, but not exactly the same, so don't be surprised by things appearing in one and not the other, or having slightly different names or meanings. Duncan

2 1