On Fri, 2006-08-11 at 12:15 +0100, Simon Marlow wrote:
The whole thing is easier to understand IMO, and it's simple to implement too: no ordering, conditionals can be evalutated independently.
I think that having the semantics of 'package()' in a configuration test be to just check for the availability of a package in the environment must be wrong. It's usually not what you want, and when it is what you want you shouldn't be doing it! :-) configuration: debug build-depends: HUnit >= 1 configuration: package(HUnit>1) ghc-options: -DHUNIT11 So if we use the debug flag then we depend on HUnit-1.0 or later. In the second configuration stanza we're merely asking if a later version than HUnit-1.0 is available to be used, not if we've already decided to use it. This is probably not what we intended. If 1.0 and 1.1 are available then we get -DHUNIT11 even if we're actually using 1.0. So yes we can make the conditional test more complex to get just what we did mean. People are going to make mistakes doing that because you'll only notice it's wrong in the situation that you've got 1.0 and 1.1 installed. So do we ever want to be able to make decisions based just on what's available? No. I don't think you do. Well, one may do but one shouldn't. Every time we're picking up an optional dependency it should be controllable by the user or package manager. So in the above case the first stanza is fine because the 'debug' flag can be set at configure time. So the point is, it's fine to adjust the build configuration depending on what packages we ended up building against, but automatically changing the build configuration based on the environment is not ok. For convenience we can get pretty close to that by specifying externally controllable flags that control the build configuration and additionally providing a mechanism to pick sensible defaults for those flags based on what's available. Most developers like the idea of automatically enabling features when the dependencies are available. Packaging people will tell you that this is evil and that it must be possible for it to be an explicit decision, even if we normally pick a sensible default to enable most features. So I fear that if the syntax allows it, developers will do it. Hence the syntax & semantics must be such that all decisions based on what's in the environment be overridable. Interestingly for the fps/base case we do not need a user flag, it really is an automatic decision. Once we've fixed the version of base we're using then there is no choice about whether we use the external fps package or not. build-depends: base configuration: package(base==1.0) build-depends: fps>=0.8 Duncan