On Wed, 2006-10-25 at 12:32 +0300, Einar Karttunen wrote:
On 25.10 01:36, Duncan Coutts wrote:
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.
Nice to get this going, this is the most important missing feature in Cabal from my perspective.
Yes, many things are blocking on this.
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
Add '(' cexp ')' and '(' fexp ')' to the syntax.
Yep.
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?
We can already do "available( P > 1 & P < 1)" (the version syntax supports such things).
Yes there's already a full range expression with union and intersection.
I think simple independent test makes things easier to understand. But there were some counter examples in the old discussion I think.
Yes I agree. Were there any significant ones? I think I objected at first, but that was on the basis that the 'package' test should be for the package that we're actually going to use. That aspect is already contained in this proposal, so I can't think of any examples for this. One other bit that is not totally clear is, if ghc allows multiple versions of a package in a single lib/prog, then does available( P > 1 & P < 1) refer to a single package or a single version of a package? In general I've no idea how we're supposed to deal with being able to use multiple versions of a package. I think in most cases it'd break anyway. You can only really us multiple versions if you don't expose anything in an interface. For example if Cabal tried to satisfy this: build-depends: foo = 1.0 configuration: os(windows) build-depends: foo = 1.1 by using *both* foo-1.0 and 1.1 then I expect that's going to break and it's not what the author intended. This is something we'll have to address eventually.
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
This can be solved quite easily:
2) we depend on P version V. 3A) V=1.1: the first configuration matches, and we signal an error as we require two different versions of P.
I'm not sure it's that simple. In normal circumstances, if we had both 1.0 and 1.1 available and def default Cabal had picked the latest version 1.1, then the first configuration might suggest it be sensible to backtrack and try with 1.0. Of course as we know, in this case that will not get us anywhere. Here's a more real example: build-depends: foo >= 1.0 configuration: os(windows) build-depends: foo < 2.0 So suppose that we know that there's some additional version constraint on one platform. Suppose also that we have foo-1.0 and 2.0 installed/available. By default at the moment Cabal picks the latest version of each package. So we'll end up finding that version doesn't satisfy the constraints on windows. So the obvious solution is to backtrack and try foo-1.0 instead. So, can we determine if there is a solution? Duncan