they aren't actually a warnings, even if the one about includes says so.
in qmake it is possible to suppress it by disabling *all* warnings, but
that makes no sense.
Change-Id: I16121f7aff0836d516139927333bd2df1f599dda
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
the line numbers are limited to unsigned short in the parser and
consequently the evaluator. as that's an internal detail that could
change any time, the display works with ints. so the special value ~0
needs to be converted to -1 in the right place.
Change-Id: Ia9437164b88ecf2077ffc4c01d7e16033970df1b
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
this makes us independent from the random access performance of the
underlying container.
Change-Id: I0e655320ad607ac43ef6797e52e6179570c155f4
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
will need a second entry path, so it's better to have them separate
Change-Id: I52bce5de536fd0ef5d6773d8177550b8d6202d1d
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
this is a more natural naming scheme
Change-Id: I376b16d14924d6c816b4eeab5169f54890164388
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
it's basically the most generic unchecked eval function possible.
Change-Id: I8f6ec5c0f35d132500b80912f8d7b221bc183c85
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
"(eval)" does not exactly help to find the error source.
Change-Id: Iecd03e6a4909ca6d7eab846844ca4415ebfa3429
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
all callers use the same value, so just inline it in the function.
Change-Id: Icc3f1301ec332cb18f5011b8abfb20703e94a491
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
as other output code which is enabled only in full qmake mode, this
prints directly to the console.
Change-Id: I6a1578818512fa3b0773faf276a1d56881eb06d7
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
the tracking is meant for literal values only.
Change-Id: I46b29f07010412bbdf2eddcec8ab28774abed4d9
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
it's not sufficient to load the qmake.conf only any more.
Change-Id: Ic699ad5e202d6f3e115e44621b4c6ee2def6edd2
Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
QString::replace(QRegExp) pretty much always detaches, so the equality
check was bogus.
Change-Id: Iee9043c1ee3083edaf289886ac11b3e3a501d623
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
there is actually a qmake test for that.
don't copy anything which is related to loading a qmakespec to the new
evaluator, though - either it will actually load a spec (include(,into))
anyway, or it has a clean slate ($$fromfile() and infile()) and anything
spec-related would be pointless.
Change-Id: I291201a2bf823e863b3ec94be91762954612417d
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
i broke this by switching to using a separate evaluator. the new
evaluator has an empty file stack, so the check would be pointless.
fix it by recoding and traversing the call chain.
Change-Id: Icb1f19adc6e66a865cd5be78eeb1c10072b4f8fc
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
MSVC warns about pm being unused (because settings() is static)
Change-Id: I750804cc52edc71649545bc03f798a6802c87c7d
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: hjk <qthjk@ovi.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>
QMAKE_INTERNAL_INCLUDED_FEATURES is added even before loading the first
prf file, so the check for an empty value map would never trigger. use a
flag variable instead.
Change-Id: If0af31d8466eadb90eca2a2e4024eff03b54e3b1
Reviewed-by: hjk <qthjk@ovi.com>
instead of re-generating mkspecPaths on each use (which is exactly once
for the makespec itself and additionally any queries of $$[QMAKE_MKSPECS]),
do it only once.
now projects don't need to inherit the root env's m_qmakepath any more,
as they are guaranteed not to need rebuilding the cache. instead, they
must inherit the cache, obviously.
Change-Id: Id8e80279a11e8d975b73fd542ecc36d24c57f2f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
just clearing the cache to signal the need for reconstruction is a pretty
safe way to ensure that every subproject will do the same work.
now projects don't need to inherit the root env's m_qmakefeatures any more,
as they are guaranteed not to need rebuilding the cache.
Change-Id: Ibc0b2d39dabf4a47430975ad30c6b32689de7854
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
03a84a7e5 re-introduced them unnecessarily after 55cad4a42 made them to be
evaluated by the parser already.
Change-Id: I1a121567fdd791f5c47c23babc4946a11b3e1f31
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
now that the basic variables are not magic any more, we need to make
sure they are initialized.
Change-Id: I75a9b66b95f84599fb9af1f4787a752319344fcb
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
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>
- 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>
no matter how little we actually use from the included files, we need to
record that we included them in the first place.
Change-Id: If09efc78f6aff4189101b21bfa040c28cefbb579
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
as far as qmake is concerned, anyway
Change-Id: I3b974e495ece4f4c30b737198c74dacfda8dbd0f
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>
