while we evaluate the features themselves in precise mode (which is the
reason why they can error out), we do not want them to terminate
cumulative project evaluation.
Change-Id: I70f3e1bcb2ca04a70c74ff484749ca92c1cf6372
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
(cherry picked from qttools/90ee4094161b427c32581bca2f5286edb4fffdb1)
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
assigning a relative path to QMAKESPEC or QMAKESPEC_ORIGINAL (in the qt4
windows legacy code) would lead to an assert further down the line.
just ignore such attempts silently.
Task-number: QTCREATORBUG-8477
Change-Id: Ie53d0ef004c743284b85de4e89f112e0161ff4b7
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
(cherry picked from qtcreator/e017a1dc8b2030e509d6198315e9f6a9869667e7)
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
QProcessEnvironment caches keys, so we must not pass it QStrings created with
fromRawData()
Task-number: QTCREATORBUG-9142
Change-Id: I29fade02f3bc4110fafb1b04d44f2e653951a2ae
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
(cherry picked from qtcreator/99f15f1706868c4b2f84bc4164451bd69b3b8188)
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
we execute foreach loops now. this is (mostly) safe nowadays, because
a previous change added precautions against exponential value list
growth, so it's unlikely that two nested loops would keep the cpu busy
for a day as before.
we continue to exclude forever loops and loops with excessive integer
counts.
Task-number: QTBUG-8550
Change-Id: Iaa116086986cc7fd5023834753f791dd205102e5
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
(cherry picked from qttools/dd4d594c787a62fa8aa12695c5d115c71b59bacd)
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Deprecate the qmake variable DEPLOYMENT that was used for installing
files on remote devices for Windows RT and Windows CE Visual Studio
projects. Use INSTALLS for both nmake and Visual Studio projects.
[ChangeLog][core][qmake] Deprecated the qmake variable DEPLOYMENT in
favor of INSTALLS.
Task-number: QTBUG-21854
Change-Id: Ia9d2c69feb7d87b0b9dc69ff7c0a68be35a57acd
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
this makes it possible to use these functions without an evaluator.
Change-Id: I23e4ec141b427f4c3c8b647305532be179058c07
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
a single quote must not disrupt a double quoted string and vice-versa.
Change-Id: Ibb277bc1c930a7dbe9199ca572507ababbcfae4c
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
it always returned true nowadays.
an obvious followup effect is that the return value of parsedProBlock()
doesn't need to be null-checked any more as well.
Change-Id: I782785cab9b721a78a342a010921a73e642ebe7f
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Use x86 for a 32 bit build of qmake and x86_64 for 64 bit.
This is needed for shells that do not set VCINSTALLDIR.
Change-Id: I0843c1a590161669530b99f45ab59d523e6596c3
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
When using the cross-compiler toolchain for 32 bit on a 64 bit machine,
qmake generated a 64 bit VS project.
This was because qmake didn't know about the amd64_x86 cross-compiler,
and qmake did not use the first MSVC bin directory it found in PATH.
Task-number: QTBUG-43457
Change-Id: I50c6f7bb9afe44a58321c670d680dbcc7cd07223
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Instead of trying to load in ltcg.prf and cache the value.
Change-Id: If485ff68fc6ff9d9cf7009cd72d5e702d0199c7f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
msvc thinks that it's impossible to create a null reference (because
some language lawyer said so) and thus complains about our assert that
checks the reference's validity. work around by not dereferencing the
pointers we already have.
Change-Id: Ife2288d4187860105de12fdebc0e671e0159ace3
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
it leads to pathological cases where the number of loop iterations may
go way beyond the reasonable.
this means that users need to avoid using the = operator in alternative
branches that lead to different sources/subdirectories being included
into the project. this is a bit of a corner case anyway, as people
usually add directly to SOURCES/SUBDIRS.
Task-number: QTCREATORBUG-1595
Change-Id: I7783e318fbc2790f6a853ba4e3f4a12db881feb5
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
(cherry picked from qtcreator/30bd7fcce1aef974f6af9eaa6532aa1f2b6192d2)
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
some qt prfs use this variable, so better set it it to avoid some noise.
Change-Id: I606c88dd7664b1cd8b490d60badd5c6bf80fd1c9
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
(cherry picked from qtcreator/e64cc71194cbe283dfe9bd2cd688f01fcdcadf34)
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this pretty surprising behavior would interfere with building the
examples from an installed qt tree with qmakes from other qt builds.
.qmake.conf (and .qmake.cache) files provide a possibility to explicitly
"anchor" project roots, so there is no point in having a second, even
more magic way to do it.
Task-number: QTBUG-35485
Change-Id: I8fd4fda67cabafdf55e7a98282dcdfaffb4a405e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
unlike .qmake.cache & co., the presence of this file has no magic
effects on where mkspecs, modules and other things are searched.
as the obvious name "cache" is of course already taken, we call it
"stash".
the file is searched up to the super cache (if present), otherwise up to
the normal cache/conf (if present), otherwise up to the root.
if it's not found, it is created next to the super cache (if present),
otherwise next to the cache/conf (if present), otherwise in the current
output directory.
note that the cache really should be created and populated by the
top-level project if there are subprojects: otherwise, if there is an
"anchor" (super/cache/conf), subprojects would race for updating the
cache and make a mess. without an "anchor", each subproject would just
create its own cache, kind of defeating its purpose. this is no
different from the existing "cache", but it's worth mentioning that
removing the "anchoring" function does not remove the "nesting order"
constraint.
Task-number: QTBUG-31340
Change-Id: I786d40cef40d14582a0dd4a9407863001bec4c98
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
there is no point in setting the variables already when peeking into
the caches, as that is done in a separate evaluator anyway.
it also makes no sense to have them set while loading the spec itself,
as it's not permitted to do anything with the caches.
so set them at the next convenient point, which is right before actually
loading the caches.
Change-Id: I3717ddf94353dc04e12c52e542f16ed27b578e14
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Allows project files or mkspecs to call qmake recursively using system()
with the right arguments, which we use to fix the ios default_post.prf.
Change-Id: I90d69e2b156bb0f0af1279188b11f81c84c24fb8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Allows the macx-xcode mkspec to be a wrapper around other mkspecs.
Since QMAKESPEC can now be set in the spec, we have to ensure not
to append to QMAKESPEC.
Change-Id: Idf33ff38147f14c488f14b426c02d9a739fdaecf
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Exclusive builds uses setExtraConfigs to apply the particular CONFIG
of each build pass. Unfortunately we were not applying these extra
configs early enough in QMakeEvaluator::visitProFile() for them to
be picked up/usable by default_pre, something that can be useful.
Change-Id: I423a4688250a15f0c1a2cc65a48f0bbc14ad4497
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The extra variables only need to be applied once, when we
are loading the pro file (and hence are loding pre files),
not for every single pri/prf that's loaded as a result of that
(which do not load pre files themselves).
Change-Id: I3118694a8eeccf2dc32c4f62df754033fad13528
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
ARGS already exists, but is a flattened list of the arguments, so both
foo(bar, baz) and foo(bar baz) will give count(ARGS, 2), making it
unreliable for validating arguments to qmake functions.
Change-Id: I0bcc16614c64000169431327da48fd1a26708e67
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
sync up; this doesn't actually do anything in qmake.
as we modify the environment, it must be properly locked.
this implies that initFrom() also needs to be called with a lock.
Task-number: QTCREATORBUG-9835
Change-Id: I48bae9af9adaa0518e5a9db0ba08ff057ae14f9f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
(cherry picked from qtcreator/d022a2d19cecb00397c2a215fc4e3bf64b1e627b)
sync up; this doesn't actually do anything in qmake.
creator's file watcher can trigger many parallel, entirely
non-hierarchical project reloads. if there is enough of them to exceed
the thread pool size, some will be serialized already by qtconcurrent,
not by our wait condition. these should notice a faulty spec, too.
Change-Id: I8ce40cb90fbc28045127881d57ec94e125df79af
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
(cherry picked from qtcreator/759d0a69dd3973b4785b6f9412f46666a05cdf85)
use the new parser flags to report all i/o errors directly.
as a notable side effect, the "WARNING" prefix is gone (even though
it is still treated like that, which is mildly insane to start with).
Change-Id: I084375d5e7a3314ae763795f7c318804a9fb84b6
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
sync up with qt creator - for qmake itself, this is just a minor
refactoring.
Change-Id: I833253f81c3159056fab2ff888f293b36cc2ef56
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
(cherry picked from qtcreator/66802ef8bf7989dc025e34bf91d93576189c483c)
(cherry picked from qtcreator/69542826fa643a0fed2fc9e717f072c2852dc017)
(cherry picked from qtcreator/196424115338fb9a535810704b7d814d318b0462)
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
it's not necessary to immediately re-calculate the roots after assigning
QMAKE_PLATFORM - it's sufficient to do it on-demand, so merely
invalidate them. this avoids that we re-calculate them multiple times
without ever using them in between while processing specs with
distributed platform assignments.
Change-Id: If508594764811b96a577fc81c5ded34ab0453148
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
(cherry picked from qtcreator/28df27d924bb407791a76de8159c9ffa6efde283)
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
looking up the same files in the same locations over and over again
is a rather significant waste. in particular, looking up the CONFIG
flags that don't correspond with features has a measurable impact on qt
creator's project loading time.
Task-number: QTCREATORBUG-9154
Change-Id: Ibae3d8b7797e706a6416a7d45c77734ab1281b51
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
(cherry picked from qtcreator/fa27cd79e05aed4ebd16d5648480cc7d48fefd43)
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
contrary to what one may expect, it's actually *not* supposed to remove
the meta-characters it interprets.
luckily, this function is not used much any more ...
Task-number: QTBUG-31877
Change-Id: I2b60f9b173140da78db2b07b596cc2e5f6e6d555
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The POSIX function uname() can return any non-negative value for success.
- Example: Solaris 10 returns 1 on success.
See: http://pubs.opengroup.org/onlinepubs/009695399/functions/uname.html
Change-Id: Ic3d51f94a31d8b562b28a2d09df3d31b04c77dc8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
this avoids that an empty rebuild after a complete build re-runs qmake
everywhere again.
according to 1f83f0cf2a this is the behavior i originally intended,
but somehow it got lost when switching to the new interpreter.
Change-Id: Id5158d7e272fdee4f4a041fb7c828295a0a86684
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
instead, teach qmake to use the mkspecs dir from the source dir as well.
Change-Id: I9edac11f8997fcb0594d0a67419d4733dd4ed86b
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
these files function as "anchors" for mkspecs/ and features/ directories
used by projects which load these files. ironically, these files didn't
see these feature files themselves.
Change-Id: I590855eb4a9d2c72b9abfcaa431d2f85a719c6e2
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
we were finding features/ directly in the source & build root, and we
were finding features/ under mkspecs/ from $QMAKEPATH and other mkspecs
locations, but we omitted the "transitive hull". this was
counterintuitive.
Change-Id: I9823e6606467c98f264c81385250da92311f51ca
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
(cherry picked from qtcreator/95169eb8e39c6f43b7e74fbb18d4db19a38b0124)
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
let the backslash escape only quotes (and itself), after all - $$list()
(one of the main users of this function) is commonly used with (windows)
path lists, so letting it escape anything would make a royal mess.
Change-Id: I2dae2e4508903e62c190c1497da68d53978118e7
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
any of the directories may be the root, which would lead to double slashes
in the constructed filenames.
Change-Id: I053e167a19b795b40e780fc29db356c7f24d286a
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Instead of after parsing the makespecs, were we assumed QMAKE_PLATFORM
had been set by the makespec and did an explicit update.
Allows loading platform specific features from within a makespec after
updating QMAKE_PLATFORM.
Change-Id: I0eb3b7fb88ce48b00a384850c5d87223c06234d7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
$$(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>
instead of symlinking (on unix) or creating a forwarding spec (on
windows), just put the default specs into (the bootstrapped)
QLibraryInfo.
Change-Id: I595500ef7399f77cb8ec117c4303bc0a2ffe505f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
This is an automated change performing the following replacements:
join\("(.)"\) -> join('\1')
join\(QLatin1String\("(.)"\)\) -> join(QLatin1Char('\1'))
join\(QStringLiteral\("(.)"\)\) -> join(QLatin1Char('\1'))
Change-Id: I9c9964703dedfdab6e7bfac80be22bd5570e2e49
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
the original value is not used any more after the final resolution.
Change-Id: Icadc219f045a1bbfd20506c4c72c53d1fb352969
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the functions are not versioned or scoped, so user-defined overloads would
mess up qmake's own feature files. it seems safer to break user projects
than to allow the user to break qmake.
Change-Id: I020a2e6416bbb6e2fd2ece339629d848c00c8398
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
cpp files should include their own headers first (but below config.h)
Change-Id: I10ef37854843ae6438d68f96ce5ee83eede33db5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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.
(cherry picked from qtcreator/f53ed6c4b3feca59a94d4f0de8b1a7411122e30e)
(cherry picked from qtcreator/f529e22ec38fb9a656d74394e484d2453cf42c69)
Change-Id: I59c8efa0e4d65329327115f7f8ed20719e7f7546
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
this is a monster commit which does the following things:
- import the evaluator as-is from qt creator into qmake/library/
- integrate it into qmake's makefiles
- overwrite proitems.h with actual special types
- remove the parts of Option which are redundant with QMakeGlobals
- make QMakeProperty a singleton owned by Option::globals. the dynamic
handling so far made no sense.
- make QMakeProject a subclass of QMakeEvaluator, with relatively few
extensions
the changes to existing qmake code outside project.* and option.* are
minor. implementing the changes gradually would mean changing a lot of
code which will be just replaced in the next commit, so i'm not wasting
my time on it.
Change-Id: I9746650423b8c5b3fbd8c3979a73228982a46195
Reviewed-by: Qt Doc Bot <qt_docbot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
