Extend the detection of the MSCV_VER variable and make VS 2022 known to
the vcxproj generator.
[ChangeLog][qmake] Added support for Visual Studio 2022.
Pick-to: 6.2 5.15
Fixes: QTBUG-97975
Change-Id: Id2c0a0b7800f721e9e34189f0a40ba4830283578
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Extra compilers with "CONFIG += combine" were broken for qmake's vcxproj
generator since forever.
Usually, extra compilers are handled by attaching the Custom Build Tool
to the input file. This is not possible for combine extra compilers,
because they map multiple inputs to one output. We cannot attach the
Custom Build Tool to the output either, because this would result in
circular dependency errors (output trying to create output itself).
To fix this, we create a custom build tool fake file (.cbt) for the
output and attach the Custom Build Tool there. This is the same trick
we do for regular extra compilers that have C++ sources as
input (e.g. the one that generates moc_predefs.h).
Pick-to: 6.2 5.15
Fixes: QTBUG-94806
Change-Id: Ib808a43fead737df91b89a1ac5e180aeae37efae
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Extra compilers and the command set to "\n" would result in malformed
<Message> tags in vcxproj files. Those tags are used to display the
name of the extra compiler when building. Setting the extra compiler's
command to "\n" is a common trick to force the creation of the rule.
Make sure to trim the command name that is created from the extra
compiler's command to avoid such new-line-only bogus message tags.
Pick-to: 6.2 5.15
Change-Id: I1bae28ed14c438d777f96280c6b2cf5ca315b51c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If we create OBJECTS_DIR at qmake time, Xcode will not consider this
directory as created by the build system, and "xcodebuild --clean" will
fail.
Prevent qmake from creating that directory in the Xcode generator.
Pick-to: 5.15 6.2
Fixes: QTBUG-96305
Change-Id: I874bf34a4289ce5f2d3e2ce070ffbe56d5368861
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The vcxproj generator completely ignored QMAKE_CFLAGS and did only read
QMAKE_CXXFLAGS. The msbuild-internal "cl compiler tool" contains the
flags for both, C and C++. It is to risky to take all QMAKE_CFLAGS into
account for the "cl compiler tool", because this might collide with what
is specified in QMAKE_CXXFLAGS. Therefore, we only read the
/std:... compiler option from QMAKE_CFLAGS and set the
LanguageStandard_C flag in the msbuild file.
Pick-to: 6.2 5.15
Task-number: QTBUG-89296
Change-Id: I885061802c1350b293a7868d4c9a9367d30e2380
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Handle the compiler flags /std:c11 and /std:c17 and turn them into the
values stdc11 and stc17 for the LanguageStandard_C tag.
Drive-by change: Add /std:c++20 to the list of known C++ standard
options.
Pick-to: 6.2 5.15
Task-number: QTBUG-89296
Change-Id: Ia575fff611bdf795406db84bd34057d008c8a383
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a subsequent comment we will set the qmake variable MSVC_VER to 16.8
to check for the availability of certain compiler flags that were
introduced in that compiler version.
The old code compared exact version strings. With this patch we're
checking version ranges instead and handle MSVC_VER 16.x as VS 2019.
Pick-to: 6.2 5.15
Task-number: QTBUG-89296
Change-Id: I9ea24a66f68a342a72f5c2a285bafacb8786661b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
"-framework Foo" arguments must be placed in the inherited_linker_flags
variables instead of dependency_libs.
Pick-to: 5.15
Fixes: QTBUG-2390
Change-Id: Idec4115533ed1f86f44db64931fa64cadeeb4572
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before this change, next() was the only way to advance the iterator,
whether the caller was ultimately interested in just the filePath()
(good) or not (bad luck, had to call .fileInfo()).
Add a new function, nextFileInfo(), with returns fileInfo() instead.
Incidentally, the returned object has already been constructed as part
of advance()ing the iterator, so the new function is faster than
next() even if the result is ignored, because we're not calculating a
QString result the caller may not be interested in.
Use the new function around the code.
Fix a couple of cases of next(); fileInfo().filePath() (just use
next()'s return value) as a drive-by.
[ChangeLog][QtCore][QDirIterator] Added nextFileInfo(), which is like
next(), but returns fileInfo() instead of filePath().
Change-Id: I601220575961169b44139fc55b9eae6c3197afb4
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This fixes build errors with Xcode 10.
Xcode 10 build system (a.k.a "New Build System") needs to know the input files
in order to build a correct dependency graph. Especially when a build is not run
for the first time and files changed in-between.
Task-number: QTBUG-71035
Pick-to: 6.0 6.1 5.15 5.12
Change-Id: If8fbad3a1915add9b35c79131b03cdbe6b7ac06d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This fixes build error with XCode 10.
XCode 10 build system (a.k.a "New Build System") requires all the files
that are generated by scripts and used later on build to be explicitly
defined as output files.
Task-number: QTBUG-71035
Pick-to: 6.0 6.1 5.15 5.12
Change-Id: Ibec39eee53b0cb3acecf592f1ca53c04b9975cad
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
By default, qmake does not compile source files that are included in
other source files. The new CONFIG option compile_included_sources
disables this behavior.
Pick-to: 5.15
Fixes: QTBUG-90801
Change-Id: I60c997938895f3a743d32ea385efdbe6bcf315bb
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Q_MOVABLE_TYPE was conceived before C++ had move semantics. Now, with
move semantics, its name is misleading. Q_RELOCATABLE_TYPE was
introduced as a synonym to Q_MOVABLE_TYPE. Usage of Q_MOVABLE_TYPE
is discouraged now. This patch replaces all usages of Q_MOVABLE_TYPE
by Q_RELOCATABLE_TYPE in QtBase. As the two are synonymous, this
patch should have no impact on users.
Pick-to: 6.0
Change-Id: Ie653984363198c1aeb1f70f8e0fa189aae38eb5c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
These look like leftovers (API flaws).
Construction of QFileInfo from QString (or similar) should be not
implicit, as QFileInfo construction is expensive (might hit the file
system), and this may have users overlook APIs (for instance build a
QFileInfo out of QDirIterator::next(), instead of using ::fileInfo();
using QDir::entryList instead of entryInfoList; etc.).
Leave an opt-out mechanism to ease porting.
Fix a handful of usages around qtbase, with at least a couple of them
likely to be actual "sloppy" code.
[ChangeLog][Potentially Source-Incompatible Changes][QFileInfo] Most
QFileInfo constructors are now explicit. The
QT_IMPLICIT_QFILEINFO_CONSTRUCTION macro is provided to keep old code
working.
Change-Id: Ic580e6316e67edbc840aa0c60d98c7aaabaf1af6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Move some lines into createSedArgs. This is used
in follow up patch.
Pick-to: 5.15
Task-number: QTBUG-87154
Change-Id: I226f4aad4aaf703a4726c42b40afb4bde3a9d878
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In commit 68866b1a7b we introduced a bug:
At a point where the first output of an extra compiler is extracted, we
try to evaluate the first output as qmake variable. This is as
nonsensical as it sounds and leads to malformed extra compiler output in
vcxproj files.
Pick-to: 5.15
Task-number: QTBUG-87601
Change-Id: Ib9aaf8a6eed8c69243f364554325c240d0bfc7f4
Reviewed-by: Miguel Costa <miguel.costa@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
6d9ec41f6f changed the behavior of
QSettings::NativeFormat for .plist files.
Previously an array of values was flattened into a multi-key QMap.
Now that QMap doesn't support multiple values for the same key,
the array is returned as QVariantList.
Adjust the code to take that into account.
Task-number: QTBUG-87218
Change-Id: I0cbf8ac7ef10b81539a29d1e68a09a40d3fe74ca
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Any but the last /MERGE:from=to option passed to QMAKE_LFLAGS was
ignored. Now, the first options gets a <MergeSections> tag and all
further options are added as AdditionalOptions, because vcxproj files /
the VS property editor do not support multiple MergeSections entries.
Pick-to: 5.15
Fixes: QTBUG-86062
Change-Id: I65bddf0b8c7ed6c162008d6ad1b58c2aba2d07d9
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
For those who are providing their own launch images for their iOS
projects then QMAKE_IOS_LAUNCH_SCREEN can be set to point to the
location where the launch image to be used over the default.
[ChangeLog][Platform Specific Changes][iOS] Added support for
specifying a launch image to be used for an iOS project. This can be
achieved by using QMAKE_IOS_LAUNCH_SCREEN.
Change-Id: Ibb236655b282132ab5eee747986a93abb9802200
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
src/corelib/text/qunicodetools.cpp:1243:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
src/corelib/text/qunicodetools.cpp:1247:55: warning: this statement may fall through [-Wimplicit-fallthrough=]
Change-Id: I441000db46cb6d85a5dcd0534ea2168b39a3f3bd
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The change creates a slight source incompatibility. The main
things to take care of are
* code using printf statements on list.size(). Using qsizetype in
printf statements will always require a cast to work on both 32
and 64 bit.
* A few places where overloads now get ambiguous. One example is
QRandomGenerator::bounded() that has overloads for int, uint and
double, but not int64.
* Streaming list.size() to a QDataStream will change the format
depending on the architecture.
[ChangeLog][QtCore][QList] QList now uses qsizetype to index into
elements.
Change-Id: Iaff562a4d072b97f458417b670f95971bd47cbc6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The original expression seems to have been accidentally
changed during the port.
Amends a1947aeffe.
Change-Id: I87821e1e025621a5efaf7a1e4f946fd3109fb256
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
While removing winrt code too much code was removed. The
ProjectConfiguration is needed for every Visual Studio project.
This patch amends 45b0f1be68
Fixes: QTBUG-85086
Change-Id: Ic8b42583a159d5b69c0c4e82f46dd98ad8e54ce2
Reviewed-by: Miguel Costa <miguel.costa@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Macros and the await helper function from qfunctions_winrt(_p).h are
needed in other Qt modules which use UWP APIs on desktop windows.
Task-number: QTBUG-84434
Change-Id: Ice09c11436ad151c17bdccd2c7defadd08c13925
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This option changes the order of include paths, which can cause problems
of various kinds. See https://bugs.debian.org/958479 for an example.
The benefit of that option is minimal for what it was intended.
Pick-to: 5.15 5.12
Change-Id: I80eeabd09764df290b60bc59aeb2f90d07723608
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I generated a rc file using VS2019 and I found that it's
using other macros.
According to [1], both of VOS_NT_WINDOWS32 and VOS__WINDOWS32 refers to
"File was designed for 32-bit Windows", although they have different
values, and 0x0L is the value of VFT2_UNKNOWN. So I think it's safe to
update them. VS2019 is using them as the default template for rc files,
after all.
[1] https://docs.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource
Change-Id: Ibaf91394668844492f1357da05b881b9d81aa15f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Setting the QMAKE_MANIFEST variable doesn't have
any effect for MSVC. This commit fixes that.
If the developer is setting this variable,
he/she will definitely use CONFIG-=embed_manifest_exe
or CONFIG-=embed_manifest_dll at the same time,
so I think there is no need to check this.
Change-Id: Ie32b7e0cded71efcf14bf4c0eecab5ab1944fa2c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All it's uses have been replaces with QRegularExpression.
Change-Id: I5bcdfdd8a39dad6d1288f18f1b24d2eea9e028d2
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
Use the DotMatchesEverythingOption for all places
where we interpret .pro files, to increase compatibility
with QRegExp.
Change-Id: I347d6b17858069f3c9cedcedd04df58358d83f27
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Should improve performance and is going to be required in
the future anyway.
Change-Id: I89d7c50441d2491da1ab0a4d564dcc91f52ade85
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Since TARGET at this point contains the path to where the target will
be then it can include ".." as part of it which will cause problems when
building for Android on Windows. Therefore, QMAKE_TARGET should be used
as an identifier here as the path is not needed.
Change-Id: Idb8babd0459c65cbcfd64fe47baeac4303a3fd87
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This is required, so that QHash and QSet can hold more
than 2^32 items on 64 bit platforms.
The actual hashing functions for strings are still 32bit, this will
be changed in a follow-up commit.
Change-Id: I4372125252486075ff3a0b45ecfa818359fe103b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The Qt version was added in 5.14 "for use as eventual replacement for
QString::SplitBehavior." Move another step closer to that goal.
Change-Id: I3f1b836cfb47bba0fdc27f2c3aa7b0576d123dca
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
