October 2006 - cabal-devel

Re: cabal (./Setup.hs) options
by Duncan Coutts 04 Dec '06

04 Dec '06

On Tue, 2006-08-08 at 10:45 +0200, Johan Tibell wrote: > > Hi, > > > > I like Cabal. There are a few things that I'm used to from autotools which > > I can't seem to find: dry-runs, uninstall and a "make distcheck" equivalent. > > <snip> > > > uninstall > > Removes all files and directories created by install > > Ditto. This is really necessary since otherwise I'll have to build a > Debian package anyway before I can install the Cabal package. Getting > software of my system is almost as important as getting it on there in > the first place. Prevents my system from deteriorating over time. I think we didn't include this feature deliberately for some reason. Isaac can you remember? > Would it be hard to implement? Anything I could do to help? In general the way to help is just to submit patches with an accompanying explanation/motivation/rationale. 'darcs send' does the "Right Thing"tm, i.e. it sends them to the cabal-devel list. Oh and everyone is invited to join the cabal-devel mailing list. Subscribe here: http://www.haskell.org/mailman/listinfo/cabal-devel Our main bottleneck on Cabal development is not the lack of people pointing out shortcomings but the number of people sending patches. Send more patches, the last ones tasted great! Duncan (wearing his Cabal patch reviewer hat)

8 12

[Otakar Smrz] Cabal's `sdist` on Win32
by Isaac Jones 01 Nov '06

01 Nov '06

Can any windows folks vet this idea? peace, isaac

4 6

Configurations proposal
by Duncan Coutts 31 Oct '06

31 Oct '06

Hi All, Before the 6.6 release we had a longish discussion on how to do configurations and their semantics and implementation complexity etc. I would like to re-propose the last scheme that I cam up with. I'll try to make it a concrete proposal as well as giving some motivating examples to give the intuition of the meaning. Key points: It's crucial that the user / packaging system have control over optional aspects of configuration. For example it is verboten for a package to just inspect the current environment and decide to use a package just because it's available without the user getting any say in that decision. (Eg a user might want to build a package to depoly on another system where that optional package is not available). What it certainly allowed is for a package to state conditional dependencies, that is a package may say: "if you, the user, force me to build using base-1.0 then I absolutely require fps-0.8". So the user / packager must have complete control over the environment that the package sees. On the other hand, for convenience it's ok for the default decision about these optional things to depend on what's available, the os or whatever. It's just important that any defaults be overrideable. So that motivates a design that separates decisions based on the environment from conditional requirements that are intrinsic and independent of the environment. So I propose two kinds of stanza: flags and configurations. flag ::= "flag:" name "default:" fexp fexp ::= "available"( dependency ) | "os"( STRING ) | "arch"( STRING ) | fexp || fexp | fexp && fexp | !fexp | True | False conf ::= "configuration:" cexp fields cexp ::= "flag"( STRING ) | "using"( dependency ) | "os"( STRING ) | "arch"( STRING ) | cexp || cexp | cexp && cexp | !cexp | True | False So flag default values can depend on what packages are available in the environment. There's no restriction on the packages that are named. The default value may also depend on the OS and architecture the package is being configured for. (We should consider splitting this into host and target arch). The idea is that these named flags turn into user tweakable settings but with sensible default values. For example they might turn into check buttons in an IDE or --enable-foo flags to the cabal configure command line. We could certainly allow and optional description of the flag. Here are some examples: flag: debug default: False synopsis: Whether to turn on debug checks or not. description: Enabling debugging turns on blah blah blah .... flag: gui default: os(windows) || (available(gtk>=0.9.10) && available(cairo>=0.9.10)) As for the meaning, it's not clear to me if it should be that each test is independent of if all constraints must be satisfied on a single package simultaneously. That is if we have a expression like: available ( P > 1) && available ( P < 1) does there have to be a single package P with versions satisfying both constraints (ie impossible) or if the tests are independent and so may be satisfied by there being both P-0.9 and P-1.1 available. I'm not sure it really matters, so we should go for the simple independent test meaning. Opinions? Now for the configurations. The point of view here is that we already know exactly the versions of packages that the builder has chosen for us to use and all we can do is adjust our build settings on that basis or complain that we need more packages to be able to build under these conditions. If we need more packages then the build agent may let us have them or not. (in which case configuration fails). So let's look at a few examples: configuration: flag(debug) cpp-options: -DDEBUG other-modules: Thing.DebugUtils build-depends: SuperDebugLogger >= 1.1 configuration: flag(gui) && os(windows) build-depends: Win32 >= 2.0 configuration: flag(gui) && !os(windows) build-depends: gtk >= 0.9.10, cairo >= 0.9.10 configuration: using(base < 2) build-depends: fps >= 0.8 Note how in the last example, there was no flag involved. This conditional dependency has nothing to do with aspects of the 'outer' environment, it depends only on what packages we've been told to build with. So some fields in the stanza just affect internal aspects of the build like exposing more modules or using some cpp defines or whatever. The more tricky ones are the ones that ask for more deps. There are a few corner cases here. Remember that at the point that we are evaluating the configuration's guard expression have decided on the exact versions of packages that are going to be used. The easy case is adding a new dep, then it's up to the builder (ie Cabal) to figure out if that dep can be satisfied. If it can then the version that Cabal decides on is added to the set of packages we're using and we carry on. If it's not available then the configuration fails. The harder cases are: * adding a build dep on a package that we already depend on, but with a version constraint that is not satisfied by the version that was already selected. * adding a dep which causes the guard of another configuration to change. In the first case I would suggest that this configuration fails. However it may not be total failure, the build agent may re-try the configuration with a different set of package versions (if it has any flexibility in that area - depending on what's available and on any user policy). In the second case I would suggest that we allow configuration guards to change from false to true but not the other way around (ie it would be a configuration failure and an error on the part of the package author). This allows us to do a simple fixpoint and make the result independent of the order of the evaluation of the configuration guards. So the restriction on a guard changing from true to false would ban examples like: configuration: !using(foo) build-depends: foo Since supposing that foo is not in the top level build-depends then ! using(foo) will be true in which case we'll add foo. But now that changes the guard. The alternative to banning this kind of case is to simply ignore any changes from true to false, but then I think we'd get a bit of oddness and the evaluation order would matter in some strange cases. Can anyone think of any sensible examples that this rule would get in the way for? I mentioned earlier that the build agent might need/decide to backtrack if it found that the versions of packages it chose did not satisfy the extra build-deps introduced by some configuration stanza. How about we start with True as the Can anyone see if it's possible to find out a priori if there is a set of packages that can satisfy the conditional constraints. Is this a standard constraint solving problem? Does it have a solution? Here's a nasty example: configuration: using(P = 1.1) build-depends: P = 1.0 configuration: using(P = 1.0) build-depends: P = 1.1 Duncan

5 15

Re: [Haskell] RE: package mounting
by Duncan Coutts 30 Oct '06

30 Oct '06

On Mon, 2006-10-30 at 08:51 +0000, Simon Peyton-Jones wrote: > I think most of you know that GHC 6.6 made (IHMO) a significant step > forward, by allowing a program to contain multiple modules with the same > name, if they are from different packages. That means that package > authors can choose module names freely, rather than worry about > accidentally colliding with other packages. (We'd regard it as > unacceptable if the local variables of a function could not have the > same name as the local variables of another procedure!) > > That still leaves an open question, not resolved by GHC 6.6: what to do > if you want to import module M from two different packages into the same > module? (A related question is when you have to decide what your module > is called.) This can be tackled in at least three different ways, one > being Frederik's proposal. Simon and I are not wedded to any particular > one, and we'd welcome a consensus on what to do. > > The state of play is summarised here > http://hackage.haskell.org/trac/ghc/wiki/GhcPackages > which includes a link to the package-mounting proposal. > > If you care about this stuff, do debate it -- and please record points > that survive a bit of discussion on the Wiki pages. None of this is > very hard to implement; the difficulty is settling on a good design. Fairly closely related to this issue is the question of how Cabal is supposed to deal with building packages that expect multiple versions of a dependent package. Currently this should actually work. If you specify: build-depends: foo = 1.0, foo = 2.0 Then cabal really does pass "-package foo-1.0 -package foo-2.0" to ghc. However it's less clear how we should make it work with configurations where we need to be able to add additional constraints on a package version: build-depends: foo configuration: os(windows) build-depends: foo >= 2.0 So should this mean that we get two versions of package foo? We need to be able to both in fact; add extra versions of a package and add extra version constraints to an existing package. Duncan

1 0

Re: Configurations proposal
by Brian Smith 29 Oct '06

29 Oct '06

(sorry, I responded to the wrong list) On 10/24/06, Duncan Coutts <duncan.coutts(a)worc.ox.ac.uk> wrote: > > On the other hand, in Gtk2Hs I know one case where we do this. We have a > Graphics.UI.Gtk.Cairo api module that is only included if Gtk was built > against Cairo. In any case it could be faked by using cpp to just not > export anything rather than not having the module exposed at all. So > it's not clear that it's worth banning. Or maybe making it slightly > harder is worth it so that people don't get in the habit. Couldn't you split this into Gtk and Gtk-Cairo packages, where the latter is only built if Cairo is available? Similarly, in your GUI example, couldn't you have seperate foo and foo-gui packages, and only build the foo-gui package if the GUI libraries are available? Otherwise, how can you say "I depend on the Gtk package being built with Cairo support" and "I depend on the GUI portion of the foo package?" In general, optional groups of modules should be split off into separate packages, and there should be a way of building a bundle of related packages together (just like one can build a group of related executables together already). Regards, Brian

3 11

Cleaning .x and .y files
by Ian Lynagh 17 Oct '06

17 Oct '06

Hi all, I think Duncan has already said that we need a way to have .x and .y files included in sdists, but we also need a clean variant or flag that doesn't clean them. Apologies if this has also already been pointed out and I missed it. Thanks

2 1

Escaping when generating register.sh
by Ian Lynagh 16 Oct '06

16 Oct '06

Hi all, The register.sh script generated by runhaskell Setup.hs register --gen-script with Cabal 1.16 is not escaping quotes correctly, e.g. with the OpenGL package in extralibs it contains echo 'name: OpenGL [...] OpenGL is the industry's most widely used and supported 2D and 3D [ ^^^ ] [...] haddock-html: /usr/share/OpenGL-2.1/doc/html' | /usr/bin/ghc-pkg update - Thanks Ian

2 1

Re: Haddock source tar file name
by Duncan Coutts 16 Oct '06

16 Oct '06

On Mon, 2006-10-16 at 12:36 +0100, Simon Marlow wrote: > Sven Panne wrote: > > I've just seen that the .spec file has been changed for Haddock 0.8, but I am > > a bit unhappy about that change. The change was that the source tar file is > > not "haddock-0.8.tar.gz" anymore, but "haddock-0.8-src.tar.gz". Although I > > can partly understand the reasoning behind the "-src", I'd like to vote > > against this change for the simple reason that Cabal's sdist does not use it > > and generates the "old" name. Therefore I have reverted the patch vote for > > repackaging Haddock 0.8 before it's too late and confusion arises. Let's > > fully use Cabal for building the source distributions and binaries without > > any obscure special cases... > > > > I would have objected earlier, but the commits/pushes to the tools don't cause > > a commit email. Could this be changed, too? > > Thanks for pointing this out. I didn't use sdist to produce the Haddock 0.8 > distributions, but I will for the next release, and I'll make sure this problem > doesn't crop up with the Happy & Alex releases. And if anyone wants to make cabal's sdist include pre-built .hs versions of happy/alex .y/.x files then that'd be great. Currently that's a manual step. Duncan

1 0

ANNOUNCE: Cabal version 1.1.6
by Duncan Coutts 11 Oct '06

11 Oct '06

The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://haskell.org/cabal/ Cabal version 1.1.6 is now available. It is included in GHC version 6.6. For other Haskell implementations or older versions of GHC you can install it separately: DOWNLOAD: http://www.haskell.org/cabal/download.html http://www.haskell.org/cabal/release/latest/cabal-1.1.6.tar.gz DOCUMENTATION: http://www.haskell.org/cabal/release/latest/doc/users-guide/ http://www.haskell.org/cabal/release/latest/doc/API/ See both the README file and the changelog for interface changes: http://www.haskell.org/cabal/release/latest/changelog BUGS: Report bugs using our bug tracker: http://hackage.haskell.org/trac/hackage/newticket or to the libraries(a)haskell.org mailing list.

1 0

4th Cabal-1.1.6 release candiate
by Duncan Coutts 10 Oct '06

10 Oct '06

Hi all, I've put up a tarball for the fourth 1.16 Cabal release candidate: http://www.haskell.org/cabal/release/cabal-1.1.5.9.4/cabal-1.1.5.9.4.tar.gz I had been hoping that this would be the final RC. One bug I've uncovered is that building the haddock docs for HUnit when cpphs is installed fails. This is because the Distribution.PreProcess.Unlit.unlit code produces incorrect output for Test/HUnit/Lang.lhs. I could do with some help in fixing this. One can reproduce it with: cd libraries/HUnit cpphs -OLang.lhs Test/HUnit/Lang.lhs --noline --strip -D__GLASGOW_HASKELL__=605 -D__HADDOCK__ ghc -e 'interact (Distribution.PreProcess.Unlit.unlit "Lang.lhs")' < Lang.lhs > Lang.hs compare this with: ghc -E Lang.lhs -o Lang.hspp and try: diff Lang.hspp Lang.hs Cabal's unlit code is incorrectly dropping whitespace and actual tokens. See especially the last part of that file. I think this needs fixing asap since the cpphs code path gets used in preference to the ghc -E path if cpphs is installed. In this example the symptoms are not too bad as it seems only to be affecting haddock, but I fear it may break more seriously in other packages. Duncan

2 3