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