On why 'available' is evil

[Simon Marlow]

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