all else being equal, items with a higher numerical priority will appear
first in the result.
Change-Id: I4ee37ff404a53c4152a1e4fc2fc3c23ef525234d
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.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>
the msys shell expects unix-like paths with drives converted
from d:\ to /d/.
Change-Id: I09e25ed2c868702e5d7d8b9cc8c04cc13410eeff
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This is useful for querying environment variables which have
parentheses in their name. Such jewels exist on Windows.
The usual $$(VARNAME) syntax fails for those.
Change-Id: I1d2766cabdc7f637caa9ae6408967685e02f5029
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
otherwise, if the output dir is the root, the path would be denormalized.
the code for finding existing files already does that.
Change-Id: I56d70477e9c9ffcd936325068624a84df10ffd87
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>
Add qjson* implementation files from corelib/json
to the qmake build. Add a read-only compile mode,
enabled by defining QT_JSON_READONLY.
Add qmake built-in function parseJson(file, into)
which parses a json file into the given variable.
qmake uses a flat key -> value-list implementation
for storing variables, which means that some hackery
is need to represent arbitrarily nested JSON. Use a
special "_KEYS_" variable for arrays and objects:
Arrays:
["item1", "item2"]
$${array._KEYS_} -> 0 1 2
$${array.0} -> "item1"
$${array.1} -> "item2"
Objects:
{ "key1" : "value1", "key2" : "value2" }
$${object._KEYS_} -> key1 key2
$${object.key1} -> value1
$${object.key2} -> value2
Change-Id: I0aa2e4e4ae14fa25be8242bc16d3cffce32504d2
Reviewed-by: Lars Knoll <lars.knoll@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.
if we end up calling cache() from within the initialization of the base
context, we cannot wait for for the completion of that initialization
before we proceed, obviously.
Change-Id: If30c6f3665fe423e767373a8821c406b2f5e0eca
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
(cherry picked from qtcreator/b64b4431c20afd9e39c1463e736f998ef450688f)
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>
this doesn't actually do anything in qmake.
Change-Id: I908fc3792bdc321370e51be98adf7a9c81e37a85
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
(cherry picked from qttools/e1f3732197ef77a29cb7f3c1ce094b3f31a7b689)
(cherry picked from qttools/226f013441990aa4a58f7c82e284057cff659959)
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>
just directly use the filename we constructed it from.
Change-Id: Ia428a2cb4b192fea6bde62dfbf35361bcfc4b21e
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
(cherry picked from qtcreator/571234786a3ff7e8e3a9220f12d22a9f74f7a53c)
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>
this is for shadow builds during build time, where the respective files
are expected in the source dir.
Change-Id: I18dcfbdef99e1562a51dacac333642cae8105ebd
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>
sync up implementation with qtcreator.
Change-Id: I6a1578818512fa3b0773faf276a1d56881eb06d7
(cherry picked from qttools/582cbddc6ba1b74a7e4e07e0b5c23d47de6838cb)
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
sync up implementation with lupdate & creator. no actual effect on
qmake.
don't filter out ^QMAKE_.*:
- QMAKE_MKSPECS is not printed any more, so needs no filtering
- QMAKE_VERSION can be simply used now, as we are now rather close to the
real qmake
- QMAKE_SPEC and QMAKE_XSPEC need to be fetched
- this fixes the default spec resolution
Change-Id: Ifcfa8b5b9e2bbf5d995940e1bb7f55e7d67aed3e
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
(cherry picked from qttools/0037bef09ca77c5ae4d20bd09294ba1d57537e09)
sync up implementation with lupdate & creator. no actual effect on
qmake.
Change-Id: I1bdeb759e895e4200f09332dadf8a6cef348182f
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
(cherry picked from qttools/94ab2efb2d155d3c1ca7b91c1daf443a149bcf1f)
this was forgotten when the value lists were extended by a size hint.
Change-Id: I6f9b55ed671224a9b8735c8d937f94aac4a73a42
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
(cherry picked from qtcreator/f24c9865306624c2fc150d4bd262a5c4d5a3689a)
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Warnings came up using MinGW 4.4:
* qmakebuiltins.cpp: 'QString windowsErrorCode()' defined but not used
[...]
Change-Id: I80827f7f740ff380f13cef96d6b43baaa7e179cb
(cherry picked from qtcreator/0e13cf3faffc7463ae2bf535dfdb008202112cc4)
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
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>
