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: