Re: Project options and other format enhancements (and dropping "variants")

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Eeek those diagrams examples in the last email wrapped horribly, I'll
try to just fix them here:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The tricky.bst is the smallest test case I could put together which
causes the engine to choose:

             tricky
             /    \
            /      \
           /        \
   tricky-first   tricky-second(second)

Where:

   tricky-first(first) -> tricky-second(first)


Things will get more complex, once you add a bit of depth to your build graph:

                   tricky
                  /     \
                 /       \
             pizza      buffalo
         (all dressed)   (naked)
              /             \
             /               \
            /                 \
    tricky-first        tricky-second(second)

Where again:

   tricky-first(first) -> tricky-second(first)

Now tricky.bst doesnt want to care about how a naked buffalo can
prepare an all dressed pizza; yet the same condition arises.

While one *could* give tricky explicit knowledge about how a pizza gets
dressed using a 'tricky-first' and suchlike; but I think things get
even more hectic once you consider that tricky.bst is not necessarily a
toplevel target, but only sometimes a target, or sometimes used in the
context of another target.

Let's try another:

            target A    target B
                  \      /     \
                   \    /       \
                    \  /         \
                   tricky         \
                   /   \           \
                  /     \           \
                 /       \           \
             pizza      buffalo       \
        (all dressed)   (naked)        \
              /             \        tricky-second(second)
             /               \
            /                 \
     tricky-first          tricky-second

Still:

   tricky-first(first) -> tricky-second(first)


Depending on the context in which tricky.bst was built, we'll get
different variants of tricky-first and tricky-second.

I guess in this case we've just shifted the responsibility up the tree
to target B, still I'm not sure how workable this would be in a larger
project with a few variants in play.

Thinking about what the user has to do in order to say; add a new
element or build a new target, it looks like when one introduces a new
low level dependency with variants; then all of the toplevels which
indirectly depend on it need to be explicit (which kind of leaves the
main advantages of ambivalence dead in the water).