Xcode resolves dependencies at the beginning of each target, so if a
Qt preprocessor such as moc or rcc updates a cpp file Xcode will not
rebuild the cpp file until the next build.
We solve this by moving the Qt proceprocesor handling to a separate
aggregate build tool target, which the main application target then
depends on.
Change-Id: I8f9225b9603dc5f279b1cb60976fe709bd97963e
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
The fallback value is an empty string anyways.
Change-Id: I77a2d3ad275321cb8b2e059fb6359f921cbc697c
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>
Non-framework builds would automatically link to whatever Qt library
matched the config at the time of running qmake, eg hard-coded to
libQtCore_debug, while Xcode itself allowed the user to switch between
release and debug configurations.
We now append an Xcode settings variable to the library path, which gets
resolved at build time depending on the current config in Xcode.
Change-Id: I12873e38a28d9595ef3fd0ae0ad849e6744833a9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
the problem is that there is no sed command on windows ... so build it
into qmake and invoke that from the generated makefiles. cmake does the
same, after all. ^^
Task-number: QTBUG-33794
Change-Id: Ib7077e18acbc5edd79f714c5779a5ed31ea6c093
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
The Xcode generator does not support exclusive builds, but still
generates projects that contain both debug and release configurations,
each with hard-coded differences such as whether or not to strip or
to generate debug symbols.
As a stop-gap solution we allow projects and mkspecs to add extra
settings that are limited to a given build. Long term we want to
rewrite the Xcode generator to support exclusive builds, but that
is a much bigger task.
Change-Id: I85056164bb1b3c8c6e0cf66410348cca7138eca5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Shared between UNIX and Win generators, and allows prfs after
default_post to rely on sane TARGET and DESTDIR values.
This allows us to clean up the DESTDIR logic in testcase.prf,
which was completely busted. Doing the two in separate commits
is unfortunately not possible as the old testcase.prf logic
was so broken it would barf if only looked at.
Change-Id: Ibf21216195c760ee46ae679c162b207b77a9d813
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
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>
It has no effect when the compiler doesn't support it.
Task-number: QTBUG-33952
Change-Id: I23b1fcdf4ec31924b1b59987846f7e0fbf17c6c9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Allows us to have scoped variables such as eg FOO[arch=armv7].
We could quote all variables, but Xcode doesn't, and we try to stay
close to the native behavior.
Change-Id: Ia6634a33e42031fe7e69c4f680803fa347e5de4a
Reviewed-by: Andy Shaw <andy.shaw@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>
A bunch of empty and never-to-be-used directories makes the build tree
noisy and harder to navigate.
Change-Id: Iebef91c82d58a8d6a0047fb5439d50eb6806f557
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
There was a mismatch of how we sanitized paths for dependencies of the
target and how those dependencies were sanitized (or not sanitized),
resulting in the target depending on 'some/path/foo.o' while the
extra compiler target was named 'some/path//foo.o', with an extra
slash. This confused 'make' enough to decide that it didn't know
how to build the dependencies for the target.
Change-Id: I181b86c291286cbbbb1f7b4c3b929a5f1dc163a3
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The pattern ${QMAKE_ needs to be at the beginning of the line, or not
start with a $ (which would make it a regular qmake variable).
Also, it's fine that the variable is of the QMAKE_VAR_foo type, as
these variables are resolved at generator time, but are constant
and do not depend on the inputs. This means we have to replace
extra variables in the output.
Change-Id: I21ad24ae770f2137e2d5d92a20ee54e2f3f4ca06
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Platform specific qmakespec needs to enable: autogen_wmappmanifest and winphone. Manifest will be generated once and only for the application template.
The Manifest will generated from following variables:
* PRODUCTID - the GUID (application specific)
* PUBLISHERID - GUID (publisher specific)
* TARGET - short application name (executable)
* AUTHOR
* PUBLISHER
* DESCRIPTION - application description
Change-Id: I225c24dc256c57451775e37658080e88b842a7d8
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The user needs to specify the DEPLOYMENT variable. The syntax
is the same as previously used for DEPLOYMENT. For more info
please refer to the qmake documentation. The change adds
a new itemgroup, "Deployment Files". All files in this
itemgroup are marked as DeploymentContent and are then
packaged with the application either as XAP or the WinRT
specific file format.
Change-Id: Icf85887287c1c97eb782704340eaa3f8dde6719e
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
In order to be able to use the linker's /WINMD
and /WINMDFILE options
Change-Id: I2673e20aa073c6b807e8c9f191fd408c7976efc4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The change adds a new ItemGroup with a single library reference:
platform.winmd.
Change-Id: I0c7f4c46654b520afb79b6c6f49b5f2d1af400d3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
It's a generic way to configure the Visual Studio Solution
architecture. It's added to support different project
architectures, ARM specifically. It may be a good idea
to replace the Win32 and x64 with VCPROJ_ARCH=Win32
and VCPROJ_ARCH=x64 defined in corresponding qmakespecs.
Change-Id: I9b23f7393bf248a629c425187d6dd8859092c45c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
qmakespec for either WinRT or WinPhone have to specify
QMAKE_PLATFORM with winrt and/or winphone.
Change-Id: I87e0063881e6edd65de14adb006949247ce49904
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The Xcode generator relies on the generic makefile generator for extra
compilers such as qrc and moc, by generating makefiles that are then
executed as separate build steps in the Xcode build.
These makefiles are generated by entering a special mode in the Xcode
generator, in which case we _do_ want to resolve dependencies, so that
e.g. the files referenced inside a qrc file are added as dependencies
to the makefile rule that generates the qrc-cpp file.
Change-Id: I96bdcb165e9774a6328ae1980986fa2c6b00c6d9
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
qmake manual needs to be able to link to pages in qtdoc module,
for example, to information about Third Party Libraries.
Change-Id: I6ccaa0c3aecc54bd5d76c6b1573c797423048207
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
When building a project in VS then it would cause a rebuild
under certain situations even though a rebuild is not
actually required.
The root problem exists in VS in the following configuration:
1. A file has a custom build tool specified
2. The custom build tool has additional dependencies
3. The input file is specified in the additional dependencies
4. There are files in the additional dependency list
This is the situation with form files in Qt that have include hints
specified in Qt Designer. The include hints get specified in the
additional dependencies for the custom build tool.
What happens is that VS will process files in the additional
dependency list differently based on where they appear in the list
relative to the input file.
If a dependency appears before the input file, VS will require the
file as a build input. If you just specify a file name, VS looks in
the project directory (and only the project directory) for that file.
You have to specify the path (relative or absolute) to get VS to look
elsewhere. If VS does not find the dependency, VS thinks the project
is out of date (since the missing dependency is a required build
input) and will rebuild the input file.
If the dependency appears after the input file and the file doesn't
exist, VS does not include the dependency as a build input. Since the
file is not a build input, no rebuild is required.
Change-Id: I5af460d21ad049ed7819746fd60c98677b810692
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
as a side effect, this fixes the generators that were more bitrotted
(nmake and even more mingw).
Task-number: QTBUG-30644 #close
Change-Id: Iefa3f07125884412d091aa12b44935e5b1fb858a
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
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)
