We need to prevent the profilemanager from signaling us the removal
of the profile, since we always delete the widget anyway.
Task-number: QTCREATORBUG-7611
Change-Id: I7cd90e979e193193562c1c3605343ff09dc84b76
Reviewed-by: Daniel Teske <daniel.teske@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>
"**Unknown**" can only be ever returned when querying particular
properties, which we are not doing.
Change-Id: If972a44d7ef2d1ff60261f13e518d40c2a5e66e0
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
with the removal of the skip jump label some time ago, this condition
became insatisfiable.
Change-Id: I4fc52ca8a38e048fd37c2ae6bfaae69acf09ada0
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
in the context of possibly using the same parse result for multiple
build configurations, resolving env variables already during parsing
would be just wrong.
Change-Id: I49367b5eff5868a38c026b8bd74148e0b359fffb
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>
if a qt4 qmake is used, these properties will be missing. as we want to
use them internally, they need to be present, so fake them.
Change-Id: I88a663b56f7420d6d9dde8bc2c738f353c15a7ce
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>
