Warnings came up using MinGW 4.4:
* botan.cpp: integer constant is too large for 'long' type
* dnssd_clientlib.c, dnssd_clientstub.c: ignoring #pragma warning
* hostutils.cpp: comparison between signed and unsigned integer expressions
* qmakebuildins.cpp: 'QString windowsErrorCode()' defined but not used
Change-Id: I80827f7f740ff380f13cef96d6b43baaa7e179cb
Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>
Reviewed-by: hjk <qthjk@ovi.com>
it's a pretty braindead thing to implement control flow statements as
(built-in) functions.
as a "side effect", this fixes return() value handling for lists.
Change-Id: I59c8efa0e4d65329327115f7f8ed20719e7f7546
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
the value map stack always has at least one map on it.
Change-Id: I836de07a14754b995403065443d3758bfc6a8683
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
while this is actually just an alias for ProString (with explicit
zero-cost conversions only), it nicely illustrates the use of particular
variables. it also serves to hide the NoHash hack from public view.
Change-Id: Iaf9283c64f320ad84a77d9573d1fde6d401c49df
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
the other branch in the function also does it
Change-Id: I74e27fa0bb997b95df904f5be48d1f251814c323
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this makes it identical to the bootstrapped path used by qmake itself.
this applies only to full qmake mode.
Change-Id: I7100315fe95d0ee900f6bea2552c9292e3d1a07d
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
follow suit with qmake ...
using fputs() instead of the fancy handler functions, as this is only for
qmake, which would just print to stdout anyway.
Change-Id: I0433d8157ce8c6e580b3fec6f622896b972f7b48
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
as the branch evaluation in non-cumulative mode nowadays actually skips
code instead of merely incrementing m_skipLevel, !m_cumulative implies
!m_skipLevel. based on that we can eliminate some always true/false
conditionals, and hard-wire m_skipLevel to zero if
PROEVALUATOR_CUMULATIVE is not #defined.
Change-Id: I19569ff96f21a5074f677b873ed800a6818f1a6b
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
properly identify the function in the dispatcher, to save an additional
string comparison later.
Change-Id: I6bb88bf620f5f47416d8f58cf00050913fc3aa4b
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
qmake doesn't check if there is exactly one empty element - be it
because (theoretically) there can be no empty elements.
Change-Id: I603f2a472c02d270eafd1b3f6f9adae4349b3af0
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
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>
