Hi All,
Before the 6.6 release we had a longish discussion on how to do
configurations and their semantics and implementation complexity etc.
I would like to re-propose the last scheme that I cam up with. I'll try
to make it a concrete proposal as well as giving some motivating
examples to give the intuition of the meaning.
Key points:
It's crucial that the user / packaging system have control over optional
aspects of configuration. For example it is verboten for a package to
just inspect the current environment and decide to use a package just
because it's available without the user getting any say in that
decision. (Eg a user might want to build a package to depoly on another
system where that optional package is not available). What it certainly
allowed is for a package to state conditional dependencies, that is a
package may say: "if you, the user, force me to build using base-1.0
then I absolutely require fps-0.8".
So the user / packager must have complete control over the environment
that the package sees. On the other hand, for convenience it's ok for
the default decision about these optional things to depend on what's
available, the os or whatever. It's just important that any defaults be
overrideable.
So that motivates a design that separates decisions based on the
environment from conditional requirements that are intrinsic and
independent of the environment.
So I propose two kinds of stanza: flags and configurations.
flag ::= "flag:" name
"default:" fexp
fexp ::= "available"( dependency )
| "os"( STRING )
| "arch"( STRING )
| fexp || fexp
| fexp && fexp
| !fexp
| True | False
conf ::= "configuration:" cexp
fields
cexp ::= "flag"( STRING )
| "using"( dependency )
| "os"( STRING )
| "arch"( STRING )
| cexp || cexp
| cexp && cexp
| !cexp
| True | False
So flag default values can depend on what packages are available in the
environment. There's no restriction on the packages that are named. The
default value may also depend on the OS and architecture the package is
being configured for. (We should consider splitting this into host and
target arch).
The idea is that these named flags turn into user tweakable settings but
with sensible default values. For example they might turn into check
buttons in an IDE or --enable-foo flags to the cabal configure command
line.
We could certainly allow and optional description of the flag.
Here are some examples:
flag: debug
default: False
synopsis: Whether to turn on debug checks or not.
description: Enabling debugging turns on blah blah blah ....
flag: gui
default: os(windows)
|| (available(gtk>=0.9.10) && available(cairo>=0.9.10))
As for the meaning, it's not clear to me if it should be that each test
is independent of if all constraints must be satisfied on a single
package simultaneously. That is if we have a expression like:
available ( P > 1) && available ( P < 1)
does there have to be a single package P with versions satisfying both
constraints (ie impossible) or if the tests are independent and so may
be satisfied by there being both P-0.9 and P-1.1 available.
I'm not sure it really matters, so we should go for the simple
independent test meaning. Opinions?
Now for the configurations.
The point of view here is that we already know exactly the versions of
packages that the builder has chosen for us to use and all we can do is
adjust our build settings on that basis or complain that we need more
packages to be able to build under these conditions. If we need more
packages then the build agent may let us have them or not. (in which
case configuration fails).
So let's look at a few examples:
configuration: flag(debug)
cpp-options: -DDEBUG
other-modules: Thing.DebugUtils
build-depends: SuperDebugLogger >= 1.1
configuration: flag(gui) && os(windows)
build-depends: Win32 >= 2.0
configuration: flag(gui) && !os(windows)
build-depends: gtk >= 0.9.10, cairo >= 0.9.10
configuration: using(base < 2)
build-depends: fps >= 0.8
Note how in the last example, there was no flag involved. This
conditional dependency has nothing to do with aspects of the 'outer'
environment, it depends only on what packages we've been told to build
with.
So some fields in the stanza just affect internal aspects of the build
like exposing more modules or using some cpp defines or whatever. The
more tricky ones are the ones that ask for more deps.
There are a few corner cases here. Remember that at the point that we
are evaluating the configuration's guard expression have decided on the
exact versions of packages that are going to be used. The easy case is
adding a new dep, then it's up to the builder (ie Cabal) to figure out
if that dep can be satisfied. If it can then the version that Cabal
decides on is added to the set of packages we're using and we carry on.
If it's not available then the configuration fails.
The harder cases are:
* adding a build dep on a package that we already depend on, but
with a version constraint that is not satisfied by the version
that was already selected.
* adding a dep which causes the guard of another configuration to
change.
In the first case I would suggest that this configuration fails. However
it may not be total failure, the build agent may re-try the
configuration with a different set of package versions (if it has any
flexibility in that area - depending on what's available and on any user
policy).
In the second case I would suggest that we allow configuration guards to
change from false to true but not the other way around (ie it would be a
configuration failure and an error on the part of the package author).
This allows us to do a simple fixpoint and make the result independent
of the order of the evaluation of the configuration guards. So the
restriction on a guard changing from true to false would ban examples
like:
configuration: !using(foo)
build-depends: foo
Since supposing that foo is not in the top level build-depends then !
using(foo) will be true in which case we'll add foo. But now that
changes the guard.
The alternative to banning this kind of case is to simply ignore any
changes from true to false, but then I think we'd get a bit of oddness
and the evaluation order would matter in some strange cases.
Can anyone think of any sensible examples that this rule would get in
the way for?
I mentioned earlier that the build agent might need/decide to backtrack
if it found that the versions of packages it chose did not satisfy the
extra build-deps introduced by some configuration stanza.
How about we start with True as the
Can anyone see if it's possible to find out a priori if there is a set
of packages that can satisfy the conditional constraints. Is this a
standard constraint solving problem? Does it have a solution?
Here's a nasty example:
configuration: using(P = 1.1)
build-depends: P = 1.0
configuration: using(P = 1.0)
build-depends: P = 1.1
Duncan
