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>
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>
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
