looks more like qmake's code now.
deals better with not-yet-existing output directories as well
(QDir::cdUp() does not work with those).
Change-Id: I062e581b7a9062f176a9bf8c686bf48b19ed0975
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
it's a relic from times of entanglement with ProFileEvaluator.
Change-Id: I903c1a8a21fcb4a0c9029d0245fba56043e62718
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
this is clearly more often used and thus makes for cleaner code
Change-Id: Ic8d100cbfc4134f1b73117b4f4a5aa5a6f4e0ccb
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
it has become a trivial wrapper around values()
Change-Id: Ia3165ec4cf968588f6ad3f5a2e8abe61dcae2f59
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
follow suit with qmake ... even if the implementation is somewhat
trivial due to TEMPLATE_PREFIX not existing here yet.
Change-Id: Ifc3eda63ae278ad33b83a0570266950304f77679
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
follow suit with qmake ...
once we move currently builtin functionality to these feature files,
things would break with qt4 (which does not have them). consequently,
we provide our own fallback versions of them.
Change-Id: Ie318f3419d78214472835c41ec1388977f2e9269
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
our processing is nowadays precise enough to allow for that.
Change-Id: I0e5c7bb4b40f713f5b4cef26bb7d4c49170ae7ac
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
instantiate a complete evaluator instead of having just vars and
functions in the option object. that's cleaner.
Change-Id: I0ecd98307832ed072cebfd5b535572f7dcb103c1
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
they are not supposed to care for the project.
during concurrent evaluation, it would be more or less random which
subproject would trigger the spec loading anyway.
Change-Id: I46c9ef5c1461153b4ba9e7f9efdd106015d0c55b
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
there are no users of this yet, so it doesn't matter.
Change-Id: If1ec6ca2d2ef1755deb3caf61d1e50f91d87d2de
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
this seems to be another contender for the most useless feature ever.
follow suit with qmake. it got a less useless replacement, which will
follow here as well.
Change-Id: I5b6f7411178294acb4ef001535b46a2c37206b51
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
all the input paths are expected to be already resolved
Change-Id: I2c9b4fb5ed25aea160669dd45fe5a4f7f3e272f1
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
they are "compiler defines", with no dependency on the evaluation context.
Change-Id: I25bf006347ecd2edb501a344820e2ac11ff389e9
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
this is QMakeEvaluatorHandler, but derived from QMakeParserHandler.
the idea is that the parser can be used stand-alone, while the evaluator
needs the parser as well.
we will need it in QMakeGlobals as well, so put it there, as that is the
most central place.
Change-Id: I6ee46c0e4b2e044bf3bfc6e4235b53525ddfc875
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
follow suit to qmake:
- the spec does not need to set the host mode, especially as some
generators are multi-host capable
- the only thing the host mode affects is the path separator, which can
be done directly instead
Change-Id: I618c2c5051234b105c4bc579240aa9f669b4d958
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
