- cabal-devel - Haskell.org

darcs patch: Add --enable-shared as configure argument, and ghc-sha...
by Clemens Fruhwirth 28 Jun '07

28 Jun '07

Thu Jun 28 13:45:35 CEST 2007 Clemens Fruhwirth <clemens(a)endorphin.org> * Add --enable-shared as configure argument, and ghc-shared-options as .cabal field

1 0

Re: [Haskell-cafe] Cabal Configurations - Beta-Testers Wanted
by Thomas Schilling 28 Jun '07

28 Jun '07

Hi Pepe, I partially fixed it. A full fix would require a feature that is not yet implemented. I'll take a look at it later today. The problem was, that shim has no library section, but my compatibility translator created an incomplete one, just to carry the dependencies. The right solution would be to add them to each executable, but there they won't be check yet for them, yet. So, your Cabal file is now internally translated to: Name: shim Version: 0.1 License: BSD3 License-file: LICENSE Copyright: (c) 2006 Benedikt Schmidt Maintainer: Benedikt Schmidt <beschmi(a)cloaked.de> Library { -- library section is only there to contain the dependencies -- It is therefore marked as not buildable Buildable: False Build-Depends: unix, ghc, haskell98, base, parsec, network, Cabal<1.1.7, mtl, filepath } Executable shim { Main-is: Main.hs Ghc-Options: -O0 } Executable shim-udproxy { Main-is: Shim/Udproxy.hs Ghc-Options: -O0 -main-is Shim.Udproxy.main } Please, update cabal+configs. > > > configure: Reading installed packages... > > Configuring shim-0.1... > > Setup.lhs: Error: Non-empty library, but empty exposed modules > list. Cabal may not build this library correctly > > > If this is a bug, let me know as soon as it's fixed. > I want to use the os() predicate in the shim descriptor, is that > already working? This should work: Name: shim Version: 0.1 License: BSD3 License-file: LICENSE Copyright: (c) 2006 Benedikt Schmidt Maintainer: Benedikt Schmidt <beschmi(a)cloaked.de> Library { Buildable: False if os(mingw32) { Build-depends: ghc, haskell98, base, parsec, network, Cabal<1.1.7, mtl, filepath } else { Build-Depends: unix, ghc, haskell98, base, parsec, network, Cabal<1.1.7, mtl, filepath } } Executable shim { Main-is: Main.hs Ghc-Options: -O0 } Executable shim-udproxy { Main-is: Shim/Udproxy.hs Ghc-Options: -O0 -main-is Shim.Udproxy.main } BTW, the os() test should test for the value returned by System.Info.os . / Thomas

1 0

Cabal Configurations - Beta-Testers Wanted
by Thomas Schilling 28 Jun '07

28 Jun '07

Hello Cafe! Cabal configurations are an often-requested new feature of Haskell's packaging system Cabal. As part of my Google Summer of Code project I implemented it with the feature set of the latest proposal[1]. I would now like people to try it out and give some feedback if it solves their problems, if there are bugs with the current implementation, or if it breaks any install scripts. So, if you have written a package and think your package could profit from Cabal configurations, please adjust your package description and try to build it on as many systems as possible and report any problems (or successes). Following are some instructions to get started. Thanks, / Thomas INSTALLING [Note: The following build instructions are for a recent GHC. If you have another Haskell compiler/interpreter you'll probably have to adjust these steps a bit. Please report any problems you encounter.] You should be able to get Cabal with configurations via: $ darcs get --partial http://code.haskell.org/~nominolo/src/cabal +configs/ Before installing you might want to hide the current cabal package using (tt shouldn't be necessary, though) via $ ghc-pkg hide Cabal or $ sudo ghc-pkg hide Cabal depending on where Cabal is installed. Installing the new Cabal should be as simple as: $ cd cabal+configs $ make install user=y PREF=~/sw This will build Cabal with version 1.1.7, register it in the current user's package database, and install it to the "sw" directory of the current user home directory. Adjust the parameters to your needs. To remove use: $ make remove user=y PREF=~/sw NEW FEATURES The new constructs didn't integrate well with the conventional syntax, so I changed it to a C-style block-style syntax. (This is consistent with Haskell's use of { .. } in do-blocks; adding or replacing this with an indentation-based approach is thinkable and might actually integrate better with the rest of Cabal file syntax. So yell if you want it--but no bike sheds please! ;) The new syntax structures cabal files like this: global properties optional flags descriptions Library { library build properties and conditionals } Executable name { executable build properties and conditionals } For an example, see below. Inside the Library and executable sections you can now use conditionals with the syntax: body: cabal_stanza "\n" body | "if" conditional "{" body "}" [ "else" "{" body "}" ] body | <nothing> conditional: "os(" string ")" | "arch(" string ")" | "flag(" flagname ")" | "True" | "False" | "!" conditional | conditional "||" conditional | conditional "&&" conditional | "(" conditional ")" Note that you cannot test for dependencies directly. The user either specifies certain features she wants by switching flags on or off during the configure step or Cabal picks a suitable flag assignment for you, depending on which dependencies are available. Unless specified otherwise, flag assignments default to True. ATM, the only field specifying dependencies is "build-depends". Options specified inside a conditional are (mostly) added to the values specified outside. E.g. GHC-Options: -Wall if flag(debug) { GHC-Options: -DDEBUG } when built with flag "debug" set to True will be built with GHC-Options: -Wall -DDEBUG For a more detailed description see[1]. The following example .cabal- file should demonstrate the features (it is also available and updated at[2]): Name: Test1 Version: 0.0.1 Cabal-Version: >= 1.1.7 License: BSD3 -- License-File: LICENSE Author: Thomas Schilling <notme(a)nospam.com> Maintainer: Thomas Schilling <notme(a)nospam.com> --Homepage: http://www.example.com/ Synopsis: Test package to test configurations Description: See synopsis. . Really. Category: Useless Flag Debug { Description: Enable debug support Default: False } Flag NoBuild { Description: Inhibit building this package. -- defaults to True } Library { Build-Depends: base Exposed-Modules: Testing.Test1 Extensions: CPP -- flag names are case insensitive if flag(debuG) { CC-Options: "-DDEBUG" GHC-Options: -DDEBUG } if flag(NoBuild) { Build-Depends: nonexistentpackage } } Executable test1e { Main-is: T1.hs Other-modules: Testing.Test1 if flag(debug) { CC-Options: "-DDEBUG" GHC-Options: -DDEBUG } } When configuring it with the usual command line, you now get an additional line, showing which flags were chosen: $ ./Setup.lhs configure configure: Reading installed packages... Configuring Test1-0.0.1... configure: Flags chosen: nobuild=False, debug=False Setup.lhs: Warning: No license-file field. configure: Dependency base-any: using base-2.1.1 [...] Note that, even though the default for the "nobuild" flag was True, the required dependencies weren't present, so it was forced to False. If you want to force flags to certain values you can do so by giving the --flags or -f flag to configure. Listing the (case-insensitive) name forces it to True, putting a "-" in front of the name forces it to False. For example: $ ./Setup.lhs configure -fdebug configure: Reading installed packages... Configuring Test1-0.0.1... configure: Flags chosen: nobuild=False, debug=True Setup.lhs: Warning: No license-file field. [...] or $ ./Setup.lhs configure --flags="-debug nobuild" configure: Reading installed packages... Configuring Test1-0.0.1... Setup.lhs: At least the following dependencies are missing: nonexistentpackage -any $ Note that if you want to change the configuration of a package, you have to ./Setup.lhs clean first, to make sure everything gets recompiled. Good Luck! [1] http://www.mail-archive.com/cabal-devel@haskell.org/msg00282.html [2] http://hackage.haskell.org/trac/hackage/wiki/CabalConfigurations

1 0

Broken Cabal on Windows
by Neil Mitchell 27 Jun '07

27 Jun '07

Hi I've got Windows, GHC 6.6.1 and I just tried to upgrade Cabal. Now Cabal is totally broken on my system. >From the Cabal directory: $ darcs pull $ runhaskell Setup configure $ runhaskell Setup build $ runhaskell Setup install All completed with a nice pile of warnings, but no errors. Then from any other Cabal package directory: D:\sources\temp\catch-0.1>runhaskell Setup configure <interactive>: C:\Program Files\Haskell\Cabal-1.1.7\ghc-6.6.1/HSCabal-1.1.7.o: unknown symbol ` _Cabalzm1zi1zi7_DistributionziCompatziFilePath_slash_closure' ghc.exe: unable to load package `Cabal-1.1.7' Obviously this breaks Cabal entirely on my system. Thanks Neil

1 1

darcs patch: Added documentation. (and 25 more)
by Thomas Schilling 23 Jun '07

23 Jun '07

Mon May 28 23:12:21 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Added documentation. Tue May 29 22:59:58 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Extended low-level parsing routines to also allow labelled blocks and if-blocks. Tue May 29 23:03:44 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Added Configuration parsing and simplification. Wed Jun 13 19:21:14 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Abstracted variables out of conditions. Generalized simplification function to accept an arbitrary partial assignment of these variables. Wed Jun 13 19:22:30 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * fixed typo Wed Jun 13 19:23:09 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * added docs Wed Jun 13 19:24:16 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * add flag as a section Wed Jun 13 19:35:48 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * add line numbers to all field times Wed Jun 13 20:43:32 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Prototypical configurations Thu Jun 14 14:50:31 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Pretty printing of conditions and CondTrees. Non-dependency information of CondTrees is now a modifier. Move CondTree resolution functionality. Mon Jun 18 21:53:29 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Compatibility parsing and working configurations. Mon Jun 18 21:54:49 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Add commandline support for specifying defaults for flags. Mon Jun 18 21:57:10 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Add helpers for reading and writing the file to hold a configured cabal-file. Sat Jun 23 22:04:53 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Fixed warnings, added documentation, and changed os and arch names to simple strings. Sat Jun 23 22:05:22 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Fixed warning Sat Jun 23 22:07:01 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Make explicit that reading package descriptions isn't supported here, ATM. Sat Jun 23 22:11:35 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Fix warnings, add documentation and changes in response to some interface changes. Sat Jun 23 22:12:54 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Fix warnings. Sat Jun 23 22:14:55 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Downcase flagnames. Re-add config flags (were removed due to update). Sat Jun 23 22:15:46 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Adjust to new package reading interface. Sat Jun 23 22:17:23 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Fix warnings. Sat Jun 23 22:20:17 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Add proper handling of configurations to configure command. Sat Jun 23 22:23:33 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Fix typo. Sat Jun 23 22:31:21 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Disable (comment out) tests for now. Break due to changed interface. Sat Jun 23 22:39:39 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Properly fix tests. Sat Jun 23 22:47:06 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Re-add configurations module to .cabal file. (Got removed on update.)

1 0

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 14 Jun '07

14 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 14 Jun '07

14 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