[ChangeLog][qmake] Introduced the variables
WINDOWS_TARGET_PLATFORM_VERSION and
WINDOWS_TARGET_PLATFORM_MIN_VERSION for overriding the default values
of WindowsTargetPlatformVersion and WindowsTargetPlatformMinVersion in
Visual Studio project files.
The code to determine the default values is moved to qmake feature
files. A common/windows-desktop.conf file is introduced for variables
common to all non-UWP Windows mkspecs.
The package_manifest feature uses WINDOWS_TARGET_PLATFORM_VERSION as
default value for WINRT_MANIFEST.minVersion, and
WINDOWS_TARGET_PLATFORM_MIN_VERSION for
WINRT_MANIFEST.maxVersionTested respectively.
Task-number: QTBUG-53654
Change-Id: I251ec7f9b804c9bc9f7d571f5b43d52b2a2d99d3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This allows others to link to QtDBus and the other libraries/tools using
doxygen.
Fixes: QTBUG-60933
Change-Id: I026895a432a328f224c40cf231ad12d109dc648f
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
Reviewed-by: Martin Smith <martin.smith@qt.io>
The correct name is c++1z. Anyhow, this is easy enough to get wrong,
so make sure CONFIG += c++17 works as well.
Task-number: QTBUG-67527
Change-Id: Iea26b18824b38b1b5170f85987cf5c750b8e10ab
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: André Hartmann <aha_1980@gmx.de>
it must end up in front of QMAKE_LIBS{,_PRIVATE}, but not of
LIBS{,_PRIVATE} (which are preceded by QMAKE_LIBDIR).
Task-number: QTBUG-61982
Started-by: Liang Qi <liang.qi@qt.io>
Change-Id: Id3de01ee0e9b66af02f79949aeb5a0eabd55363f
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
the early merging of LIBS* into QMAKE_LIBS* meant that we could not
interleave them properly. defer the merging until the points of use.
Task-number: QTBUG-70779
Started-by: BogDan Vatra <bogdan@kdab.com>
Change-Id: I890f98016c3721396a1f0f6f149a9e2b37d56d8e
Reviewed-by: Liang Qi <liang.qi@qt.io>
CONFIG+=lrelease enables that all .ts files in
TRANSLATIONS or EXTRA_TRANSLATIONS are compiled by
lrelease.
EXTRA_TRANSLATIONS is a new variable that is only
processed by lrelease, but not lupdate - this
is useful for translation files that are supposed to
be empty, because they match the language of the
original translation sources.
If embed_translations is also set, the generated .qm
files will be made available through the Qt resource
system under :/i18n/. Alternatively, the user can
specify an installation target by setting
QM_FILES_INSTALL_PATH.
Note that relative paths in TRANSLATIONS are not taken
into account. That is,
TRANSLATIONS = component1/de.ts component2/de.ts
will cause a conflict.
[ChangeLog][qmake] New CONFIG options lrelease and
embed_translations were added. CONFIG+=lrelease does
run lrelease on translation files listed in TRANSLATIONS
and EXTRA_TRANSLATIONS. CONFIG+=embed_translations does
include the generated .qm files as resources under
:/i18n/.
Change-Id: I94db5b8431d07b24f59b2c332ede91450f9c0c58
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This reverts the following commits:
d12d2949d126c3bec09b49b08f96e8
We can't easily predict all code paths for QDesigner
with such a microoptimization. We also don't want
to generate three different string constructions
depending on some sophisticated heuristics.
[ChangeLog][uic] The -no-stringliteral option is now deprecated and
UIC will not generate QStringLiteral anymore.
Task-number: QTBUG-65251
Task-number: QTBUG-51602
Change-Id: I34a5a1934a8df19c5c84ac2ba8e5168ce5665037
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Fixes the default C version used with gcc < 5
Change-Id: I948dece961caed8e6b181e1c6e6b9dc43c46583e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Thanks to QTBUG-61373, this qmake function was called with
/usr/local/5.10.1 as baseDir, which isn't absolute, leading to an
assertion failure. We could raise the error within qmake but it
proved easier to simply resolve any non-absolute baseDir using PWD,
before trying to use it as an absolute path.
Did the same for $$absolute_path(). Documented both. Adjusted the
assert that caught this to report any non-absolute path that upsets
it. Added simple tests, fixed an existing test.
Task-number: QTBUG-66156
Change-Id: Icfef2e2f5b236e071177c9beffa38d71bf404292
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Removed duplicate "for the".
Function list was sorted except for sprintf; so sorted it. Also, minor
grammatical improvement.
Task-number: QTBUG-64362
Task-number: QTBUG-64363
Change-Id: Ia47c5195011a0e578e916897b3a5ddb1d78170ad
Reviewed-by: Frederik Schwarzer <schwarzerf@gmail.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Make it clearer what the variable actually does by mentioning
that it makes its headers available for inclusion and causes
it to be linked to the binary.
Change-Id: I72821d4bceea7a92e91175ba6c5acc4c3377d7b7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
These are no longer part of Qt 5 and produce documentation warnings.
Change-Id: I82242b7b03d7ece1b82e2ff75dc6673f471e2df2
Reviewed-by: Martin Smith <martin.smith@qt.io>
MSVC requires that the C PCH file is compiled (as an object) and linked if
any C file is found, and the same for C++.
Most qmake projects are C++.
If a C++ project has a precompiled header, it is typically of C++ type, and
cannot be compiled as C (for example, it contains or includes classes).
Since there is no easy way to conditionally build the C PCH file only if C
files are found in the project (as done for g++), we need a setting that is
disabled by default.
This amends 30331afda1.
[ChangeLog][Tools][qmake] Introduced precompile_header_c CONFIG option for
MSVC to enable precompiled header for C sources.
Task-number: QTBUG-65103
Change-Id: Id9688a35ee7d9b5e4f5a846b81986cb674bc5f4e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This ensures that the same set of variables can be successfully replaced
in both the Makefile and Xcode generators. It also switches the default
templates to use the Xcode-style ${var} syntax instead of the @var@
syntax for better Info.plist compatibility across generators.
Change-Id: Iff330bafd152773aafac9143c4a34e34f92f0ce6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The update adds the moduleheader variable to the qdocconf
file for qttestlib.qdocconf and qmake.qdocconf. The problem with
qmake is that it doesn't have a module header file, but it does
have qmake_pch.h, which is used here. This update also corrects
several \fn commands in the qttestlib docs.
Change-Id: I2202b9db96390bac1ee491ca8a99ca9010057ce3
Reviewed-by: Martin Smith <martin.smith@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
QMAKESPEC is added in makefile generator,
it is not in INCLUDEPATH.
Change-Id: I2451b3c7b30bc237157e68e5ce9de67f55e784b2
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
When a ObjC++ QObject subclass is listed in the regular HEADERS, qmake
creates a .cpp file. The moc file will then fail to compile, as it
requries ObjC++ headers. Using Q_FORWARD_DECLARE_OBJC_CLASS() can be
used to let the class be parsed by The compiler, but link will still
fail, as the generated methods (e.g. signals) must be built with ObjC++
compiler, in case they have ObjC parameters:
Q_FORWARD_DECLARE_OBJC_CLASS(NSString);
class MyClass: public QObject {
Q_OBJECT
signals:
void objcSignal(NSString * myObj);
};
The canonical workaround for that is including the .cpp file into the
corresponding .mm file. This also offers a compilation speed advantage,
but is somewhat counter-intuitive.
Therefore, we introduce a separate variable which instructs moc to create
.mm files directly.
Task-number: QTBUG-1581
Change-Id: Ia98af58006efd168ea37f3a63c396979e7e81baa
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
... and use it when building shared libraries and plugins.
It prevents application crashes in cases when libraries and
plugins are unloaded and their strings are still used by
the main application.
Task-number: QTBUG-51602
Change-Id: I4af79183f18c5ed6142d55af02a36fe4334f3fee
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The old docs contained obsolete information. Also, the new docs
match the new docs for the other Apple OS deployment targets.
Change-Id: Id773fa2086f291d8a2552fe1b339ec1e13c19d74
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
The following variables were not documented:
- QMAKE_IOS_DEPLOYMENT_TARGET
- QMAKE_TVOS_DEPLOYMENT_TARGET
- QMAKE_WATCHOS_DEPLOYMENT_TARGET
Change-Id: I5cfb6c0024d92e943aed882fd01bc2a4f2c7c042
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
files is not a test function.
Change-Id: I6d23dac5d1c87bd35961406dd62cc3cf37d652e3
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
documentation of QMAKE_DEVELOPMENT_TEAM and
QMAKE_PROVISIONING_PROFILE
Change-Id: Id5854862e44387e31db40f574d85f88512c27f0c
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
qmake really lacks version comparing functions:
users either use ugly constructions to compare versions
by components, such as
greaterThan(QT_CLANG_MAJOR_VERSION, 3)|greaterThan(QT_CLANG_MINOR_VERSION, 4):
or even incorrectly compare versions as strings:
!lessThan(apple_clang_ver, "5.1")|!lessThan(reg_clang_ver, "3.4"):
Add test functions versionAtLeast and versionAtMost which use
QVersionNumber to compare version numbers by components.
Change-Id: I65e6b3c296d0301d544b7e38bf3d44f8d555c7fc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
the code was broken since 5.0, as it still hardcoded the version number
4 for the plugin basenames.
wince is not supported any more, so there is no point in trying to
restore the code to function.
at a later point, we'll make QTPLUGIN universal enough to cover both
static and dynamic deployment.
Change-Id: I0911ce4aff7a799dd471d6218e046f13dca6d49e
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
the normal mode forces the prompt into a pattern which may be
undesirable.
Change-Id: I01689c7a6573415801862348b32bafc6a609ed4a
Reviewed-by: Lars Knoll <lars.knoll@qt.io>