$$(FOO) would automatically split the contents of the environment
variable at whitespace (and interpret quoting inside it). the way to
prevent the splitting (but not the quote interpretation) would be using
"$$(FOO)".
this behavior is entirely unexpected and thus an incredibly effective
source of quoting problems - according to a grep over the whole qt
sources, there isn't a single case where things were done right. in qt
creator, well over half the cases are wrong.
also, the "feature" seems entirely pointless: nobody uses spaces as
separators in environment variables.
consequently, simply remove it, even in a patch release. i'm postulating
that nobody will complain.
Change-Id: I9ed3df1b0d1ef602acd78ceb118611d294561da6
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
(cherry picked from qtbase/566d28316dd73bfe4a8ea34839989ee9df7e3895)
instead of symlinking (on unix) or creating a forwarding spec (on
windows), just put the default specs into (the bootstrapped)
QLibraryInfo.
Change-Id: I595500ef7399f77cb8ec117c4303bc0a2ffe505f
(cherry picked from qttools/0e75115e557b4cf1c737e3e5524f876a6b85a39e)
(cherry picked from qttools/769fa282ac8a4b98698dada6969452363e0eb415)
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
otherwise we end up in the source tree, which is counterproductive.
Task-number: QTBUG-26869
Change-Id: Id44a94f827dc285c75b9b243c8ef6478e668e3ff
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
(cherry picked from qttools/29bdcb6008a58203efc62ee58e57d266e60be095,
plus creator-specific amend)
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
the original value is not used any more after the final resolution.
Change-Id: Icadc219f045a1bbfd20506c4c72c53d1fb352969
(cherry picked from qttools/74d548c89dae83b392953f505876d8d383a72ce5,
plus creator-specific amend)
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Some projects set TARGET or DESTDIR only in the build_pass
Task-number: QTCREATORBUG-4273
Change-Id: I3673dd93b37b10102a0c1f1ce053e1aef8aaf53f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Daniel Teske <daniel.teske@digia.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>
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>
