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.
> 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.
> 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). I think simple independent test makes things
easier to understand. But there were some counter examples in the
old discussion I think.
> 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:
1) there is no prior build-depend on P => we are not using P so ignore these.
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.
3B) V=2:
neither configuration matches and we continue happily ignoring them.
version:
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
