the performance is about the same (depending on the expression type it's
better or worse), but a lot of code just disappears.
Change-Id: I60eb9b87f23cc811d3f9577841c38966ecfd8e43
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
to optimally support cumulative mode, the parser will happily return a
bytecode object even when parsing failed, so errors must be treated
later.
Change-Id: I1a5c0ca9bf46a93d7359f590f0dd0ddc96baba0a
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
will need it later.
eval() needs to be taught to ignore the return code, as qmake stupidly
does. as a side effect, flow control statements inside eval() don't have
an effect outside eval() any more, which is only sane.
Change-Id: I924e9d687f693a224dd7fa73af4a9bc69247e2df
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
follow suit with qmake ...
this doesn't use any of the fancy handler functions for printing the
message, as it doesn't seem worth it: the read is done directly from
stdin anyway, and everything else would be overengineered, given the
purpose - this is probably the most useless qmake function ever.
Change-Id: I4831bfc06ce2623c4090d13c04be286bc18f1b5d
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
- start with capital letter (unless it's a function name)
- end with period
Change-Id: I62350ca2c632cf27334fe6acad2ad0487eef74a4
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
follow suit with qt5 qmake. this is actually wrong for qt4 qmake, but i
boldly assume that it doesn't matter.
Change-Id: I7e0ced1f335fde28f56fa6c5a4a1a581ec7e9ad0
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
instead of having a bazillion different callbacks, have only one with a
type parameter. the drain typically multiplexes all into one stream anyway.
Change-Id: I963daefc5a266c91334a4cc599570ed26b603d5d
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
if this is enabled, the evaluator implements all functionality
necessary for qmake. without it, functionality which is unnecessary or
outright dangerous in qt creator or lupdate context is omitted.
Change-Id: I233cfa6daf2e4451f9f1d3d14711be2a7cfe4293
Reviewed-by: Daniel Teske <daniel.teske@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>
it has become a trivial wrapper around values()
Change-Id: Ia3165ec4cf968588f6ad3f5a2e8abe61dcae2f59
Reviewed-by: Daniel Teske <daniel.teske@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>
the functions are still part of the same class, though.
Change-Id: I58a69d334ac9d1d53b5395d0b655895ffe18c7be
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
