make qmake evaluator perfectly cumulative

the problem we are trying to solve with the cumulative mode:
we want the union of all distinct lists of sources/subprojects a particular project file can produce.

if we take that literally, we actually need to clone the evaluator state at every branch point and evaluate the rest of the project for each of the clones. naturally, the number of clones grows exponentially with every condition, let alone when loops come into play.

what we could attempt to do is "tagging" the clones with the conditions they resulted from. when we get to the next condition, we can match it against the tag and eliminate branches that are "not compatible" with this clone - e.g., it makes no sense to evaluate the 'win32' branch in a clone that is already known to be for 'unix'. this tagging can be assisted by creating as many assertions as possible, e.g., letting the evaluator read all existing qmake specs and concluding that combinations that don't appear in there are impossible.

what the tagging does not help with is that once we cloned the state, subsequent code is re-executed for each clone even if it does not actually depend on the condition that lead to the cloning - most blatantly obvious when a cascade of simple contains(QT_CONFIG, ...) or platform conditionals is followed by some complex, but platform- & configuration-independent (file) processing, which nonetheless would be executed potentially tens, hundreds, or even thousands of times.

that can be helped by cloning/tagging variables individually. that way actual branching would need to be done only when running into data dependencies with multiple clones.

considerations:

• how to tag? it's always some expression relating to the data state itself, probably represented as an AST, normalized as far as possible.
• how do conditions that terminate loops fit in? the tags would have to have "a long trail" or something like that.
• when taking the "incorrect" branch of a conditional, the underlying data is inconsistent with what we are assuming. we can:
  • ignore that problem. this will usually work just fine, but will explode in more complex cases.
  • rectify the problem. that is, do with the underlying data whatever is necessary to make the condition actually true. the problems here are that a) we need to implement "reverse-causality" for quite some conditionals, b) often, there are many ways to make the condition true, and when we make a wrong bet, we may have problems further down the line, and c) this forced state may be internally inconsistent. c) could be somewhat fixed by validating the result against known assertions and potentially doing followup fixups.
  • avoid the problem by adopting a state that is actually compatible with the condition. it is obviously impossible to maintain the full set of possible states (number of specs, multiplied by a sheer unlimited number of configure outputs), so one would have to be constructed on the fly from available rules. this is somewhat similar to the solution to c) in the previous point, except that instead of minimally patching up whatever state we started from (typically the real state), we construct a whole state from scratch. this needs more data (where do we take it from? the problem here is that configure is not written in qmake, so we'd have to declare a lot manually) and produces more data (we'd have enough full states to satisfy every tested condition). and we could tell the user when he has impossible conditions in this project.

anyway, just in case somebody was wondering why we (the advocates of QBS) are insisting that build tools that have an imperatively structured project format (be it qmake or cmake) are inherently broken ...