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
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
