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>
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>
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>
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>
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>
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>
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>
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>
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>
Mirror the behavior in unixmake.cpp and do actually install
/uninstall files in target.targets. This fixes the installation of
.debug files on MinGW for a Qt with -force-debug-info
-separate-debug-info.
[ChangeLog][qmake] Install/uninstall rules are now generated for
target.targets on Windows. This mirrors the behavior on Unix.
Fixes: QTBUG-81354
Change-Id: Ie9366f132ebd8e18680f32f2e52cec64dbd87e9a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We must use Windows line endings in .vcxproj files to separate command
lines of custom build steps.
This amends commit f65cfadd.
Fixes: QTBUG-81553
Change-Id: I8d257f3846af7006df7f8d462b8f44efdce6a1fd
Reviewed-by: Miguel Costa <miguel.costa@qt.io>
We always pass the same value. The builtins are also using exactly this
"cd command" unconditionally.
This deduplicates the code at the call sites of
callExtraCompilerDependCommand a bit.
Change-Id: I5c412c815d50afdac55e1b45021f37f2545ce8f0
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Use the central callExtraCompilerDependCommand in the last place where
the code to call an extra compiler's depend_command was duplicated.
Note that this is in the "Bad hack" section. We're making this hack less
bad, but the comment still applies.
Change-Id: Iaa857af20ca46b2d73053d3e264c63124c87a41b
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
De-duplicate the code that calls the extra compiler's depend_command by
using the central function callExtraCompilerDependCommand. This one
actually tries to resolve dependencies unlike the removed code that
blindly resolved relative paths to the build directory.
This fixes dependencies reported by uic which need to be resolved
against what is in DEPENDPATH.
Fixes: QTBUG-80579
Change-Id: If482e50ff3eff716fefffee82004acc076b3a547
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Since commit 9ab043b6 we're checking for invalid file paths passed to
Qt's file system engine. When initializing the deployment tool for VS
projects we accidentally passed a file path containing '\0'. Fix that by
using an infix QString, not QChar.
Change-Id: Ieae066d20ac290354febd420abce68f28649b365
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
When building an application for Android on Windows it is possible that
the command line will be too long when doing the link step. So the code
for generating a response file is moved to MakefileGenerator so it can
be used by the other generators easily. The same variables used by
MinGW can be used elsewhere then.
Fixes: QTBUG-71940
Change-Id: I6c331d12e9541a90a4a95e0154d0ea1c056489bc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We must check whether outputs or inputVars are non-empty before
accessing them.
This amends commit 68866b1a.
Task-number: QTBUG-79178
Change-Id: Iecf6dc705bac9bef5133ae2e5ceeace5f859f175
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Do not resolve -l entries to absolute file paths for libraries in the
default search paths.
This restores behavior from 5.12.0 (commit 2327944d) for Windows
system libraries.
Fixes: QTBUG-78827
Change-Id: Ic2d4626df87308dd635afc1ab5c4b8191d3d2831
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
For nmake and VS projects we added the NDEBUG define for the release
configuration unconditionally within the qmake generators. To undefine
it, users had to use a nasty work-around.
Now, define NDEBUG within the MSVC mkspecs. In order to do that we
introduce the DEFINES_RELEASE and DEFINES_DEBUG variables that are
merged into DEFINES in default_pre.prf.
Users can unset NDEBUG by writing
DEFINES -= NDEBUG
in their .pro file.
Note that DEFINES_RELEASE and DEFINES_DEBUG are merged in
default_pre.prf in order to give extra compilers (like moc) the chance
to see the fully resolved DEFINES variable. This is different from the
QMAKE_CFLAGS_(DEBUG|RELEASE) variables that get merged in default_post.prf.
Fixes: QTBUG-78071
Change-Id: I381770a1d2f974fbae9b09a2254e3f2fc7842b68
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The conditions were wrong, they must compare against zero.
Also, use qstricmp to avoid the platform #ifdef.
Change-Id: I7e5ef1b9ae8e2e1d3d9ce90a645ee568b370ab57
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
The commands are separated by "if errorlevel 1 goto VCEnd" lines to
make sure we abort on the first failure. However, we also insert magic
comments starting with "Rem" for IncrediBuild. These do not need
error checking. Also, the last command does not need error checking.
The XML line ending entities are also unneeded. By using proper line
endings we ensure that commands appear on separate lines in Visual
Studio's property editor.
Change-Id: Ifbf7525281e892c820034fafc64b555fff3dc756
Reviewed-by: Miguel Costa <miguel.costa@qt.io>
The VS project generator never calls the Win32MakefileGenerator code
that sets up DEST_TARGET which is used for checking for conflicting
DESTDIR/TARGET combinations on Windows. Replicate the setup in
VcprojGenerator::initProject().
This amends commit e75aed1a.
Change-Id: I4238eb2f57615095c372cee9ada9fc961cc36133
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Sub-projects in VS solutions must have unique project names. If there
are multiple projects with the same TARGET then QMAKE_PROJECT_NAME must
be set to different values.
The .sln generation code did not use QMAKE_PROJECT_NAME and produced
.sln files with equally named sub-projects.
Replace the 'orig_target' member of VcsolutionDepend with a
'projectName' member and use it when writing the .sln file and for the
misnamed "GUID map" that's supposed to have unique keys.
This commit amends 9e750d34 (qt/qt.git).
Fixes: QTBUG-77639
Change-Id: I81c64f8bc6baeb6d99e9d5808fb73dfd7aaaeeb8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Windows resource files support a subset of C preprocessor directives.
Among others they can have #include directives.
Use QMake's own scanner to retrieve the files that are included by a
Windows resource file and add them to its dependencies.
For the test case the TestCompiler class had to be extended:
runCommand is now public, and commandOutput is less peculiar.
Fixes: QTBUG-3859
Change-Id: I138703352c37c98297c0574a9a440510c1c494b8
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QMakeLocalFileName is not suitable for QList. Use QVector instead.
Change-Id: I5a3c4c8da14c0a920b5a57cba148ad68ac0f85a2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
If a project has DESTDIR and TARGET set to fixed values, then the
target paths conflict when doing debug_and_release builds.
With this change we're detecting this situation and yield a warning.
Fixes: QTBUG-2736
Change-Id: Ib163db3463322792ab9fa5b997285ac9fc9819ab
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This undocumented option was introduced in
69c22301806b56d56cbe5f5076b889ba98e41a2b (old internal history, 2006) to
prepare some unspecified change to configure that was never done.
Change-Id: I60de731ac9bc6f6424c57574e59e9f6b4f6c5eb3
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This change allows using custom flags for ar. For instance, it is
now possible to create a thin archive by setting QMAKE_LIB += -T.
This uses and extends commit d92c25b1b4
which served a similar purpose for the linker.
Change-Id: Ie1d6a0b957dc4809957726de00911c8d91647fab
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
