Commit 8e5eb1bddc introduced the assumtion that mkspecs are
immediately below the mkspecs directory itself. This is not true for
e.g. unsupported/blackberry-armv7le-qcc.
This commit restores qmake's ability to find the "root" of the mkspecs
collection no matter how deeply the actual mkspecs are nested.
Task-number: QTBUG-24665
Change-Id: I98faaf8e6ae7b8524277aea6c17e685e507e37b3
Reviewed-by: Sean Harmer <sh@theharmers.co.uk>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
this makes the "sysrootable" properties more magic, with the raw
versions being omitted from the qmake -query output and automatically
falling back to the "cooked" variant if there is no sysroot set.
this makes the "normal" qmake -query less noisy. this will become even
more obvious when i add more "overloads" of the properties.
Change-Id: I08000986427264ec6238c8fe0a77f5cecdbf1201
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
there is totally no reason to call it unless the project is actually
used for makefile generation, and the excessive calls actually mess up
things.
Change-Id: Idb7912a5404f6054010d2f29cce820a167de4f6f
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
clean up the somewhat convoluted code paths which forced re-evaluation.
now that the spec+cache are evaluated in a completely clean context
anyway, there is no point in re-evaluating them for build passes.
Change-Id: I12279083238e9ca7028af97f45e2638c8dc715b8
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
instead of initializing base_vars with the original's vars, initialize
vars itself. this has two consequences:
- there is no need to call read(0) to initialize vars
- one cannot usefully call the complex read() anymore, as that would
re-initialize vars from base_vars
this is much closer to an actual copy than the previous "seeding with
existing project".
Change-Id: Ib007bc5b779aedb680a27329aa578f7c604a4308
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
load()/include() with a target namespace would inherit the current
context. however, if you source a project with all bells and whistles,
this makes completely no sense and may be actually counterproductive.
infile()/$$fromfile() would have interited only the functions from the
current context. that was only a hack to support abusing them.
Change-Id: I2e992b923d9e5b0e5056001ca49b35de573abc63
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this is a hack from the times when these functions were (ab)used to
inspect proper project files, but the inclusion was done with a clean
project, so that the included files did not have any functions to work
with.
Change-Id: I19925e8ead597ca38df040000c183e368b32c06d
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
merge them into before_user_vars. they are evaluated right after another
anyway.
Change-Id: I11859284b363fee01233f6e20989444fef711d0d
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
don't inject the build pass specific variables into the project even
before evaluating the .spec file and the .qmake.cache. they are not
supposed to base configuration on that - feature files should do that
later.
the immediate advantage of this is that base_vars is never manipulated
upfront any more, which allows for cleaner setup paths. also, we can do
more caching of the spec+cache contents.
Change-Id: I19d7f8bec1fb7c3b54121e26794340b287055ebf
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
instead of messing with the Option singleton, add a way to inject
extra config values into QMakeProject.
Change-Id: Ia347dcc38af2c72913e30ebf5c2b4044f93b4f5f
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this is a one-time operation which depends only on the invocation, so
this new home is much more appropriate.
Change-Id: I07c66d95a9ae01a664cec17564995311fb78ec9b
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
that way qtbase will find its spec without hacking .qmake.cache.
note that passing "-spec default" on the command line would have already
triggered the normal path, so artificial limitation did not even provide
safety against abuse (it is arguably pointless/counterproductive for
other projects than qtbase to have a default spec).
Change-Id: Ib0c3e6498fd70cd6f9561951d72a47165878bb33
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
instead of being a variable added to the makespec (via qconfig.pri),
QT_SYSROOT is now a property.
the QT_INSTALL_... properties are now automatically prefixed with the
sysroot; the raw values are available as QT_RAW_INSTALL_... - this is
expected to cause the least migration effort for existing projects.
-hostprefix and the new -hostbindir & -hostdatadir now feed the new
QT_HOST_... properties.
adapted the qmake feature files and the qtbase build system accordingly.
Change-Id: Iaa9b65bc10d9fe9c4988d620c70a8ce72177f8d4
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
that is, spec/../features/ (i.e., mkspecs/features/) - and not any
directory up to the root.
Change-Id: Ie5fdf2898fba5ac93583571edc24629471604798
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
moving the detection of .qmake.cache to the qmake startup had the side
effect that a suddenly popping up cache would not be picked up by
nested projects any more.
this is not supposed to work in the first place, but the syncqt hack for
building against non-installed modules relies on it. until we have
cleaned that up properly, we need a way to notify qmake about the
appearance of the cache file.
Change-Id: I450646b936e3bb2ef2ed3aba05df58e521ccdc61
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
qmake would look for mkspecs/ in the directory containing the current
project file. this makes completely no sense with recursive projects:
a) nobody would make per-project specs and b) specs meant to be global
would not be found.
consequently, we look for a project root when starting qmake and use
only that directory.
if .qmake.cache is found/set, we assume that to be the project root.
otherwise, we search for mkspecs/ the same way we search for the cache -
just to up until we find one or hit the root. if we are shadow-building,
search the build dir as well.
Change-Id: Ie66b189a40c21203d956e681cbef44a89f98cd17
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this is a one-time operation which depends only on the invocation, so
this new home is much more appropriate.
Change-Id: I11ef30a8227afed06e58e64e65809dba25e81567
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
it's generally redundant with DataPath which we already look into.
this is consistent with where mkspecs are looked for.
i don't think anyone will notice this "loss" ...
Change-Id: Iab7c35cc22ba53e1005f26b5d85d41cf4dafad07
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
no point in saving the context when we are not actually modifying the
current context.
Change-Id: Id6f51a163e86bdf402aa0713737b655db68e7ee8
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
we already initialize it before parsing a project. if a project is daft
enough to clear TARGET, it does not deserve differently than breaking.
Change-Id: I6c727bc27d72a00e84b676ae3c169024bdb2d929
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
The QByteArray::operator const {char,void}*() implicit
conversions are a source of subtle bugs, so they right-
fully can be disabled with QT_NO_CAST_FROM_BYTEARRAY.
const char *d = qstring.toLatin1(); // implicit conversion
while ( d ) // oops: d points to freed memory
// ...
But almost no-one ever enabled this macros in the wild
and many were bitten by these implicit conversions, so
this patch deprecates them.
I would have liked to remove them completely, but there
are just too many occurrences even in Qt itself to hope
to find all conditionally-compiled code that uses these.
Also fixes all code that needs to compile under
QT_NO_DEPRECATED (in qmake/, src/tools/).
I984706452db7d0841620a0f64e179906123f3849 separately
deals with the bulk of changes in src/ and examples/.
Depends on I5ea1ad3c96d9e64167be53c0c418c7b7dba51f68.
Change-Id: I8d47e6c293c80f61c6288c9f8d42fda41afe2267
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
base_vars["QMAKESPEC_ORIGINAL"] is not guaranteed to be set the first
time resolveSpec is called, since an include() can wipe it out. Change
it so that resolveSpec is called repeatedly until some
QMAKESPEC_ORIGINAL is set.
The code which attempted to remove all of the path up to the last / was
incorrect and must have been dead code (or its wrongness didn't matter)
until now.
Change-Id: I2b31ae10fc284ac7293c3cd95e5a2fd503ca7ab0
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
resolve only once, in particular on unix.
Change-Id: I090698fc6029322a3a16d179d461af3e8336f6ad
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
there is no obvious reason why this should happen. if base_vars is used
again, the user configs will be parsed again, too.
Change-Id: Ib56e01a468cdb5e81d610bcaf0163bf730cbae05
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this brings some clarity which combinations are actually possible, which
allows for some optimization later on.
Change-Id: I930027e426c5f9abea8d21eb1ebaa39bd29787b8
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
This change is needed because msvc2010 tools have a '\' character at
the end of environment variable VCINSTALLDIR. This variable on msvc2008
does not have this '\' character at its end. Without this change
QMAKE_TARGET.arch on msvc2010 x64 evaluates to x86 instead of x86_64.
Task-number: QTBUG-22686
Change-Id: Ifba833e9361c97568b8b3de9976023e8537b208a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
As in the past, to avoid rewriting various autotests that contain
line-number information, an extra blank line has been inserted at the
end of the license text to ensure that this commit does not change the
total number of lines in the license header.
Change-Id: I311e001373776812699d6efc045b5f742890c689
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
this should make the evaluator quite a lot faster. the total win for
qtbase/src is only 6%, though.
i made some effort to avoid that output files get randomized. however, i
didn't bother to keep debug output sorted.
Change-Id: Id9cef4674c0153c11ebbb65cb63bf8c229eb56e3
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
If you ran qmake with 'qmake -r', default_pre.prf would only be run once
while default_post.prf would run for every sub-project.
This makes it more symmetrical and correct.
Change-Id: I1d096c38dffb16f1d256c511ed9e2912cfaefe66
Reviewed-on: http://codereview.qt.nokia.com/1716
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
"default" was used a very long time ago, and it's time to let it go.
Change-Id: I230573ef778789f6e1a5a7df3543e660392da39b
Reviewed-on: http://codereview.qt.nokia.com/1746
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
the 'item' reference may become invalid inside the loop.
this approach was chosen (instead of making 'item' a non-reference) to
keep the code more in sync with creator (where the string type is more
complex).
Change-Id: I60a4b0654dc47c0e3466d43904c358eb7e3e64e2
Reviewed-By: Marius Storm-Olsen
Reviewed-on: http://codereview.qt.nokia.com/1702
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
make it a proper topological sort. before, it could not resolve diamonds
correctly.
Change-Id: I17ffd81020ab36e7e5dbcfd120793ba8d9c6cf18
Reviewed-on: http://codereview.qt.nokia.com/1435
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
that's common practice for the expand functions, and that one isn't even
particularly big
Change-Id: I66c22e11edb66bd00d211fc1282eb75f5dd4832d
Reviewed-on: http://codereview.qt.nokia.com/1456
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
... and re-add a real $$resolve_depends(), just in case.
Change-Id: I489d6056546340ce95280fe7fd571e30c14470e7
Reviewed-on: http://codereview.qt.nokia.com/1455
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
it needs to go from highest order to lowest order.
that's not relevant unless doing static linking.
Change-Id: Ieb69e3949b4d9cc2d2a62f5661f31e3dc88ac882
Reviewed-on: http://codereview.qt.nokia.com/1454
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
this is braindead, but it's consistent with the rest of qmake and more
performant. and the argument error message claimed it already anyway.
Change-Id: I973368acc6ffbff17107085ccd68b0334cc3e681
Reviewed-on: http://codereview.qt.nokia.com/1436
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
This function calculates the topological order of variables.
We will use it to determine which and in what order to link
module libraries.
The function is not tied to libraries/modules only, but requires
the variables to be ordered to have their dependencies in the
[prefix]<var>.depends subvariable.
Due to the recursive nature of the algorithm it was just much easier
to implement it directly in C++ rather than in a qmake-language
function.
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
Qt Git wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://qt.gitorious.org/qt/pages/GitIntroductionWithQt
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo, Qt master branch, at commit
896db169ea224deb96c59ce8af800d019de63f12
