issues with configurations

[Duncan Coutts]

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