Ian Lynagh wrote:
On Wed, Nov 01, 2006 at 02:04:29AM +0000, Duncan Coutts wrote:
In all this discussion on configurations I think I'm not getting over my main point about why we can't go for the 'easy' option of allowing package 'available' tests everywhere.
I don't think anyone is arguing that we should do.
So, 1: it often doesn't mean what you want
configuration: available(foo >= 2) cpp-options: -Denable_cool_feature
There's no necessary relation between what packages are available in the environment and the one(s) that the package is going to be built against. So the above will fail if we actually build with foo-1 but foo-2 is available.
What's worse is that it will likely work on the developers machine but fail on the users machine.
Am I right in thinking that your objection to removing "using" and rewriting
build-depends: foo
configuration: using (foo >= 2) cc-options: -DENABLE_NEW_WAY
as
flag: new_way default: available(foo >= 2)
configuration: new_way build-depends: foo >= 2 cc-options: -DENABLE_NEW_WAY
configuration: !new_way build-depends: foo < 2
Yes, I'm with Ian (and Brian?) here. What was missing from Duncan's original proposal was the exact way in which the user is supposed to specify which version of foo they want when there's a choice. The version with a flag and no 'using()' makes this clear: you use a flag to choose, no extra mechanism is required. Also, using() is a weakened form of available(), and has some of the same disadvantages when allowed in the conditional of a configuration. The syntax ends up a bit long-winded, but this feels like the right design to me. The *only* place you can make a choice based on what's in the local package databse is in a 'default' field. Cheers, Simon