This is C++, not qmake code. Amends 5fa6438633.
Change-Id: Ie5b88c3a06dbe089948488ea3b4b297a08164113
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
SYSTEM is used for system() calls, while SHELL is used in the target
Makefiles.
Task-number: QTBUG-62985
Change-Id: Ia75d3939c59c98699359421166433e8b4a6ee35e
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Use the writeDefaultVariables method also for the
Win32MakeFileGenerator. Remove the initializations that are already done
in Makefile::writeDefaultVariables.
Change-Id: I590cc5d7031de67dd830e6113849ab080dbf2325
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Users should use range constructors instead to do the conversion.
Keep conversion methods between QList and QVector as these will turn
into a no-op in Qt 6, whereas forcing people to use range constructors
would lead to deep copies of the data.
Change-Id: Id9fc9e4d007044e019826da523e8418857c91283
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
As the non prefixed variants are deprecated
Change-Id: I2ba09d71b9cea5203b54297a3f2332e6d44fedcf
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
QRegExp includes can be found in several files where there's not even a
use of the class. This patch aims to avoid needless includes as well as
follow the "include only what you use" moto.
This patch removes a QRegExp include from the QStringList header which
means that there is likely going to be code breaking since QStringList
is used in many places and would get QRegExp in.
[ChangeLog][Potentially Source-Incompatible Changes] qstringlist.h no
longer includes qregexp.h.
Change-Id: I32847532f16e419d4cb735ddc11a26551127e923
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Conflicts:
examples/examples.pro
qmake/library/qmakebuiltins.cpp
src/corelib/global/qglobal.cpp
Re-apply b525ec2 to qrandom.cpp(code movement in 030782e)
src/corelib/global/qnamespace.qdoc
src/corelib/global/qrandom.cpp
src/gui/kernel/qwindow.cpp
Re-apply a3d59c7 to QWindowPrivate::setVisible() (code movement in d7a9e08)
src/network/ssl/qsslkey_openssl.cpp
src/plugins/platforms/android/androidjniinput.cpp
src/plugins/platforms/xcb/qxcbconnection.cpp
src/plugins/platforms/xcb/qxcbconnection_xi2.cpp
src/widgets/widgets/qmenu.cpp
tests/auto/widgets/kernel/qwidget_window/tst_qwidget_window.cpp
Change-Id: If7ab427804408877a93cbe02079fca58e568bfd3
It was already done correctly in the GCC generators, but lacked in MSVC.
Task-number: QTBUG-11117
Change-Id: I5e6c2e4802dbe33c0f15c46a227a08c3f0cc5707
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The $${TARGET}_manifest.bak file was not removed on "nmake clean".
Task-number: QTBUG-59827
Change-Id: Ia5b636f4917f3e7a2df8d753824b72e63d278005
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
QMAKE_LINK_OBJECT_MAX is actually a property of the host, not the
target.
this works around binutil's inability to use thin LTO objects in
conjunction with an MRI script
(https://sourceware.org/bugzilla/show_bug.cgi?id=21702).
Task-number: QTBUG-61335
Change-Id: I90a1334b9c905c433b35546e8f3f3b5089d2c65b
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
If these rules are not added to the solution, Visual Studio will
complain, that the project has to be deployed before it can be run.
Change-Id: I6d3fbc949c85b11a92f78e13e2f6a1b92a5cfdc7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If several Makefiles are used in the same directory (for example, for
multiple projects in the same directory or different build configurations),
they all reference the same object_script, which is obviously wrong.
Change-Id: I9b499ceb6b6bd6058f54b452fa44bfb2313eec26
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This was already done on unix, but not for MinGW.
If the archive already exists, it is appended rather than replaced.
This can cause invalid references when whole-archive linking is used
and some object file that was already linked was deleted.
Change-Id: Ie265371f197d996d57002b248043736544ee641e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
adding shared install paths to QMAKE_{INCDIR,LIBDIR} in the spec has the
tiny side effect that they are searched _first_, which is generally a
really bad idea - they should be _last_.
for that purpose, make QMAKE_{INCDIR,LIBDIR}_POST live up to their names
(i.e., search them actually last) and migrate all affected specs to use
them.
Task-number: QTBUG-40825
Change-Id: Ie0de81c3cc49e193186d2fedd7d6c77590c8ef79
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Every /Zc:XXX option qmake doesn't know about yields a "WARNING: Could
not parse Compiler option '-Zc:XXX'; added to AdditionalOptions."
Put all /Zc:XXX options we don't handle into AdditionalOptions without
printing a warning. There's no point in making all options known to
qmake and updating them for every MSVC release.
Change-Id: I319e027791a7b0a29d139ee3074ab1aed8ce8a63
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
As the directory installation command also works with files as a source
we can unify the external commands, resulting in simpler command lines.
Change-Id: I65013626eedbdb3ce1c77ed230d46edd1603b986
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The same as for other visual studio versions use "x86" as arch instead
of win32. arch is used to determine library paths and these use x86 and
not win32.
As compilerArch is not used in MSVC 2017 it can be removed.
Task-number: QTBUG-60530
Change-Id: I47157eb1d7ae9d913461210d34858ffb37c81586
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Similar to the two parent commits, this patchs preserves the time stamps
of files we install as a result of recursive directory copying.
Change-Id: Id5931a467196d5cd67acfa0deffc2488af8a3669
Task-number: QTBUG-59004
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
As for the formatting code, de-duplicate the parsing code by only
parsing char*s, converting QChars to Latin-1 first in a small buffer.
The QUuid(const char*) ctor performed no length checking, relying
instead on the checks performed within _q_uuidFromHex(), which
includes an implicit check for premature end (because NUL is not
a valid token for the parser).
The (QString) and (QByteArray) ctors did perform length checking.
To the extent possible, this is removed, since it is handled by
_q_uuidFromHex(). Failure cases need not be optimized. Only the
QLatin1String overload needs to do some checking, because views in
general are not NUL-terminated. The QStringView overload can just
append a NUL when it converts to Latin-1.
The only check I added to _q_uuidFromHex() is that for src ==
nullptr. It would otherwise be duplicated in several callers.
While touching the internal functions, port to passing and returning
by value.
Saves 1.6KiB in text size on optimized GCC 6.1 Linux AMD64 builds,
even though we added new API.
Port some users to the new functions. Expand fromString() test.
[ChangeLog][QtCore][QUuid] Added fromString(QStringView/QLatin1String).
Change-Id: I519339419129550c86e0ea80514865cd6a768f5d
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Similar to the parent commit, this patch adds a unified code path in
qmake itself for installing program files while preserving their
original last modification timestamp.
Change-Id: I7b7dcfa6228c2bfd48ea6036549398bb6f90032f
Task-number: QTBUG-59004
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
On non-windows platforms, we use the "-p" parameter of install(1) to
preserve the last modification timestamps of files. On Windows the use
of copy does not preserve them. As a cross-platform solution, this patch
introduces a simple built-in install command in qmake to copy files.
Task-number: QTBUG-59004
Change-Id: I3064d29a2b8c7b009a1efbf8f00b84c079ea5417
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Due to that uninitialized variable /DEBUG:FASTLINK ended up in vcxproj
files for VS < 2015. However, that option is supported by VS >= 2015
only.
Task-number: QTBUG-59630
Change-Id: I34d9eef1a3bf2262bac48962938afe84eb7de934
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Adding the /utf8 compiler flag resulted in undefining all preprocessor
symbols for VS project files, because the ingenious compiler option
parsing logic checked for a 'u' prefix, and "utf8" obviously matched.
The /utf8 flag is added to the additional options, because there doesn't
seem to be an XML tag for that.
Task-number: QTBUG-59431
Change-Id: I762fcdcf6caf0606b40633861e265df5edb4a9c4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Call sites of NmakeMakefileGenerator::writeResponseFileFiles expect that
the output is terminated with '\n'. Do not bail out if files is empty.
Task-number: QTBUG-59305
Change-Id: Id3fef8dbc506dad1868e6b352119f5f27b50a368
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Linking with too many object files could lead to "LNK1170: line in
command file contains 131071 or more characters". Do not write all .obj
files into one line but respect a limit of 1000 characters. If the limit
is reached the object files are separated by newlines instead of spaces.
Task-number: QTBUG-58710
Change-Id: Ibae1f737d6b614a9624b4e00cdd21d3722d341e3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
in particular, -before (just for symmetry, as it's the default), -early
(the actual objective), and -late (for symmetry again).
Change-Id: I274303582a348b052c3e5106ff360ab4fd7d4ee2
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
[ChangeLog][QtBase][General] Removed support for WinRT/Windows Phone 8.1.
Task-number: QTBUG-57288
Change-Id: Ifd6d6780cbbdb710d99556ba3d2fb2e514d4f789
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
When generating the Visual Studio project XML, the filter "Root Files"
was not being output. Specifically, this means that even if RC_FILE was
specified, it would not be included properly as a resource compilation
target in the resultant Visual Studio project file.
This is essentially a rather belated cherry-pick of qt/d6de960b7f.
Task-number: QTBUG-57914
Change-Id: I7d03dc818df0cf36608012f1a71a3a476d8a9ff7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
now that configureapp does not use it any more, qmake is the only
remaining user. and the license headers already claimed that this code
is part of qmake ...
Change-Id: I9b8a16f8f2b432d2b1143efbdd1f0042305ccc0c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Before VS 2013 ToolsVersion contained a .NET version
number (e.g. "4.0"). Since VS 2013 ToolsVersion is the same as the
Visual Studio version number (e.g. "12.0"), which is also the default.
We always wrote "4.0" (except in one special case which used
"14.0"). This doesn't bother Visual Studio itself, but other tools
like PVS-Studio.
Remove the ToolsVersion attribute from generated VS projects for VS
2013 and newer.
Task-number: QTBUG-57694
Change-Id: I7a3bc4534c492e9540f6b968bee8a969980df63f
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change dcd2f829 introduced fake files with the extension .cbt for custom
build tools that generate code from C++ source inputs. The moc_predefs.h
header file falls into this category, because it is generated from
dummy.cpp.
It turns out that these fake files have to exist. Otherwise the
custom build step is executed on every build. That means re-moccing all
mocables on every build.
Fix this by actually creating the fake .cbt files with some
explanatory comment in them.
Task-number: QTBUG-57695
Change-Id: I251294334425d9914677787d8ba6da1169b4cca5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This tag was never spelled "PlatformToolSet". The correct spelling
is "PlatformToolset" (lower case s). VS itself can load qmake-generated
projects despite this misspelling, but tools like PVS-Studio are
bothered by it.
Task-number: QTBUG-57435
Task-number: QTBUG-57694
Change-Id: Ib70e8561f1827e195194bcf518445b2909a8d8c0
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
eliminating everying TARGET-related was a nice try, but in the real
world (e.g., qttranslations), extra compilers are activated by
PRE_TARGETDEPS, which of course doesn't work when TARGET is entirely
gone.
so instead, let it act as a phony target. this is consistent with the
unix generator.
supersedes 0810d48bc in amending af2847260.
Task-number: QTBUG-57423
Change-Id: I3d2ecc4ff42b37ffe5f71f5c20d17c06b31f4da2
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
For QMAKE_EXTRA_COMPILERS with inputs that are "buildable" (e.g. C++
sources) the custom build step is added to the output file. From Visual
Studio's point of view this looks like a circular dependency (e.g.
foo.moc generates foo.moc). Usually this just prints a warning that can
be ignored. But this circular dependency also breaks dependencies
between custom build steps. This became noticeable when the generation of
moc_predefs.h was added. Generating moc_predefs.h must be done before
any moc custom build step is executed.
This patch fixes the issue by using fake files (output file plus suffix
".cbt" for "custom build tool") that act as dummy inputs for the custom
build tools.
Task-number: QTBUG-16904
Task-number: QTBUG-57196
Change-Id: I4711e44a0551046d215db151fa0312af8a9177a2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
it's wrong to use the escape function for makefiles, as the command
goes directly to a popen() call.
Task-number: QTBUG-57343
Change-Id: I34a8e4d8fb406303c593e7c1e24019e0f756e7f8
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
The values of this hash are strings, not lists of strings.
Enforce this by using the proper type instead of just using a comment.
Change-Id: Id8a13acdceb8f9f8a9a8eaa04e790b1e6cd5faa7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
of course, we should stub out everything related to TARGET - only the
generic "all" and "first" targets including their deps should be
emitted.
amends af2847260.
Change-Id: I8ed7a550b8022c69328d2e16dbd078928d176964
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
actually pack the extra compilers' input files, not the variable names.
unlike on unix, we don't create an actual distdir, so the package is
still going to be rather broken.
Change-Id: If0a15bbe9db95aebd88c2a21ca3c0f787ce5c7e1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Replace which_dotnet_version with a simple function that converts the
value of MSVC_VER to its corresponding enum value in the VS project
generator.
This reduces the maintenance burden when adding support for a new VS
version, because we do not need to update the registry keys in
which_dotnet_version anymore.
The which_dotnet_version function implemented the following logic:
- find all installed VS versions via registry
- select the "best matching one"
- if there is no best match, select the VS that's in PATH
- create a project for that VS installation
The usefulness of this whole stunt is questionable as the VS version of
Qt's mkspec must match the version of a project using that Qt anyway.
Change-Id: I9fb9a099ee5ddb5fc4c450be4f68f41f2b406b9a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
On the way to get rid of this function.
Have one place to determine the VS version instead of calling
this function over and over again (even though all calls but
the first are cheap).
Change-Id: Ic42a65df5a9bbe289f4813e4db85000dba15e672
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Make qmake understand the /DEBUG:FASTLINK option in QMAKE_LFLAGS, and
write the corresponding value correctly to VS 2015 project files.
Task-number: QTBUG-55591
Change-Id: I670375ed1523a5ab96bb3cce28635785564edba8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Commit 3d3d65f5 separated the PDB files for compiling and linking. Only
the PDB file the linker produces would be installed. However, this does
not work for static libraries as the LIB tool does not create a PDB file
from the compiler's PDB file. This patch turns the separation between
PDB files off for static libraries.
Task-number: QTBUG-56594
Change-Id: I08dcb7889c67b2f6370efa1ee19be8558355bbc9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
With the removal of Windows CE support(52623d6d) the logic of these
checks have changed, as it was always true for non Windows CE builds
before.
This did not affect WinRT, as those mkspecs define VCPROJ_ARCH
explicitly in their qmake.conf.
Task-number: QTBUG-55753
Change-Id: Ie2eddf197c17fcbf7343b444cfe8940a332a545c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
It's empty, but non-trivial, thus preventing move special member
functions from being generated by the compiler (now that qmake
is compiled as C++11, too).
The default ctor was also empty - removed, too.
Change-Id: I714db524f681f1fc250d21926245757e97351e87
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Has a few too many fields for defining a member-swap
(which would be required to mark it shared).
Change-Id: Iecbeec9e60a9884cb4a984c58cb192918cef799d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
It's empty, but non-trivial, thus preventing move special member
functions from being generated by the compiler (now that qmake
is compiled as C++11, too).
Change-Id: I7e4b6d7f604020dd5e6da81f7a046202c8b78e09
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
It's empty, but non-trivial, thus preventing move special member
functions from being generated by the compiler (now that qmake
is compiled as C++11, too).
Change-Id: I9431311d24da802f147ce10e475936838bb85d41
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Visual Studio automatically defines _WINDLL when building a DLL,
regardless of project settings
(https://msdn.microsoft.com/en-us/library/8x480de8.aspx). This define
is therefore widely used to detect DLL vs. static library or executable
build target on Windows.
For makefiles, _WINDLL need to be manually defined, which QMake failed
to do so far.
Task-number: QTBUG-55183
Change-Id: Ic62201666c44e730e6881706d568ce9eaf22b7a4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This was only used to specify XP as a target which is
not supported on 5.8 anymore. Clean up all associated
special handling in the mkspecs and pro files.
This effectively reverts change 10a0ac75.
Change-Id: I420d73002912989f1a5be961a2d09277ec4a4425
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
And blacklisted a few tests in tst_QUdpSocket.
Conflicts:
src/android/jar/src/org/qtproject/qt5/android/QtNative.java
src/corelib/global/qglobal.cpp
src/corelib/global/qsystemdetection.h
src/corelib/io/qfileselector.cpp
src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_egldevice/qeglfskmsegldeviceintegration.cpp
tests/auto/network/socket/qudpsocket/BLACKLIST
Task-number: QTBUG-54205
Change-Id: I11dd1c90186eb1b847d45be87a26041f61d89ef6
A bug in the Windows C Runtime causes text mode pipes to drop newlines
sometimes. This bug was hidden because of another bug in rcc which
caused newlines to be redundantly duplicated. When the latter bug was
fixed (commit 53d5811b) the former bug was exposed, causing invalid
vcxproj files to be generated. The Windows bug is described here:
https://connect.microsoft.com/VisualStudio/feedback/details/1902345
The workaround is to avoid text mode, and do the conversion of "\r\n"
to "\n" ourselves (which we were already doing anyway).
Change-Id: I792599a4cd7822f109fa921f02207fb1b144b1d1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The two PDB files that the MSVC compiler and linker create are supposed
to be handled differently and should not share the same file path.
Using the same file path for both can result in corrupted PDB files and
longer build times.
Use $${TARGET}.vc.pdb in the OBJECTS_DIR for the compiler and
$${TARGET}.pdb (the default) for the linker.
Task-number: QTBUG-53895
Change-Id: I31f06d4a674a3aa2afe5b30499bae820e5caf2c4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
this introduces an ambiguity, so some char* arguments need explicit
QString construction now.
Change-Id: Ic3919a1fa9419bbb3b57dd1aa7eb95643ee59e53
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
While previous SDKs used the form "CE_SDK (CE_ARCH)" in their
configuration/platform names, this is not true fo the Toradex SDK.
Inside Visual Studio the platform is only called "Toradex_CE800"
instead of "Toradex_CE800 (ARMV7)".
In order not to break other SDKs CE_PLATFORMNAME is introduced and
used in the wince80colibri-armv7-msvc2012 mkspec. If the variable
is set qmake uses it as the platform name in its vcproj generator.
Change-Id: Icb501bf6446a9f617745a0d2c7a80b240680b043
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
Port the last four remaining Q_FOREACH users in qmake
and uic to C++11 range-for and mark all qtbase tools
(incl. qmake) as Q_FOREACH-free, using QT_NO_FOREACH.
Change-Id: Ief4e5877269e7a853e4cf05e58861a448e822d3d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
This fix repairs the mechanism to deploy Qt dlls as well as C++ runtime
to a wince target in Visual Studio.
Do this by adding a deploy section in the Visual Studio solution and
adding the C++ runtime from the mkspec to the files deployed to the target.
Deploy target path is set to what the wizard of Visual Studio defaults to.
Before, the c++ runtime was only deployed for executables which were built
as part of Qt.
Task-number: QTBUG-50924
Change-Id: I478010dc16e35c68578281895aa3ae14b5c96bb4
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
we can rely on the super class to get it right.
as a "side effect", we won't try to install .pdb files for aux projects
anymore - the duplicated conditional was incomplete.
Change-Id: I9b66f32ab50ed2a1d4e6e03a9d205686a4b4a981
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
The platform has been removed in Qt 5.7.
Change-Id: Ie768b5ffbe60270c27b4a670dcf580ea361cb361
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
They prevent move special member functions from
being synthesized by the compiler.
Change-Id: I90c4a6e286734ef3906ee833826bd3bfbdad3874
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Java-style iterators are slower than STL-style ones, so
they should not be used in library code.
Replaced them with C++11 range-for, STL iterators or, in
one case, qDeleteAll().
In one case, avoid a double hash lookup by using erase(it)
instead of remove(it.key()), which we can now do without
detaching, due to the new erase() taking const_iterator.
Change-Id: I96174657fed70f76120b2c9d8190b4e70d5d8179
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
In VcprojGenerator::collectDependencies(), a temporary QLinkedList
is created, then iterated over. There's no reason to use a node-
based container here: no references are taken, no erases happen,
esp. not in the middle...
Port to QVector instead and reserve it, since the maximum size is
known ahead of time, and the lifetime of the container is very
short.
Since the loop iterating over the linked list needed touching
anyway, port directly to C++11 range-for.
Change-Id: Ic5dfeebcd9da37c214f54abc6025a0a2b8fa3b5d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
(or trivially marked const) ... by replacing them
with C++11 range-for loops.
Change-Id: I1522e220a57ecb1c5ee0d4281233b3c3931a2ff8
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
... by replacing them with C++11 range-for loops.
To avoid detaches of these mutable Qt containers,
wrap the container in qAsConst().
Change-Id: If086bea06fe26232a7bb99fad8b09fce4dc74c27
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
... by replacing them with C++11 range-for loops.
This is the simplest of the patch series: Q_FOREACH took a
copy, so we do, too. Except we don't, since we're just
catching the return value that comes out of the function
(RVO). We can't feed the rvalues into range-for, because
they are non-const and would thus detach.
Change-Id: I5834620bf82f3442da7b2838363d351a0fb960a0
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
... by replacing them with C++11 range-for loops.
The functions QMakeProject::values(), QMakeMetaInfo::values()
and QHashIterator::value() all return by const-reference,
so they can be passed to range-for without further changes.
Change-Id: Ic3b39ed8ff8cd7a6f287f1aa9d61a1acd67d7aaa
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
... iterate over the container itself instead. Avoids
temporary QList creation as well as the lookup cost
when actually calling value(key).
Change-Id: Icac867c30e63863cfa44a382eedd4d6df2070a59
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
QFileInfo::exists(f) is somewhat faster than the version which creates an temporary object.
Change-Id: I5f931a86d9dfad57d99efe04ca115422de43def9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When building QNX on MS-Windows, make magically adds the Msys root as
prefix to variables whose values look like paths; this applies to both
environment variables and variables given values on the command-line.
When we don't actually want to install under the Msys root, this is
unwelcome "help". So (for MinGW's make) support a magic prefix of our
own, @msyshack@, that'll make a path value for INSTALL_ROOT not look
like a path to make; we can then strip it off when we come to use it.
Change-Id: I951ad3c8fe3e5cfb49e6e361d7fff779f3a9d716
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some
exceptions, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one
(in those files which will be under GPL 3 with exceptions)
Change-Id: I42a473ddc97101492a60b9287d90979d9eb35ae1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Having a precompiled header file without file extension (or without
common file extension) led to an incorrectly generated Visual
Studio project file. The custom build step for automatically
generating the corresponding source file was missing.
Remove the file extension check that apparently was yet another
feeble attempt of runtime optimization.
Task-number: QTBUG-50442
Change-Id: I0552f94be12cbb70e2f32c242c7364699979bd81
Reviewed-by: Karsten Heimrich <karsten.heimrich@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Previously the hardware and camera button handler were guarded inside a
Q_OS_WINPHONE which does not apply to Windows 10.
Instead use WINAPI_PARTITION_FAMILY like on other places, this covers
Windows Phone 8.1 as well as Windows 10.
To find windows.phone.ui.input.h at build time the Mobile Extension
directory needs to be added to the include paths inside qmake. On
runtime we need to check whether we have hardware buttons or not. In
case they exist, register the handlers, otherwise skip registration.
Skipping also helps to keep WACK succeeding.
Task-number: QTBUG-50427
Change-Id: Ibeae15dbde12553cebd2b73b1a40b754c014f426
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
the primary purpose is making env var prepend mode work for unset
variables on windows. this is achieved by using a conditional and delayed
variable expansion. however, the latter is disabled by default and can
be locally enabled only in batch files. therefore, write wrapper scripts
and substitute them for the actual commands. we do this also on unix,
both for consistency and simply because the commands look much less
confusing.
this change is slightly backwards-incompatible, as invoking
qtAddToolEnv() multiple times on the same command will now make a total
mess. also, invoking it on a command that contains 'make' macro
expansions isn't a good idea, so testcase.prf needed an adjustment. the
function is an undocumented internal, so Nobody Should Care (TM).
this also reverts 80ebedecf9, as it's obsolete now.
Change-Id: I8394b77868b495abcf27b688996ca74c40b80994
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
In 50bf54c invoking windeployqt was only required in release mode as
MDILXapCompile was not invoked for debug builds with Visual Studio 2013.
However, Visual Studio 2015 invokes MDILXapCompile for debug and
release. Hence we have to use this workaround unconditionally.
Also we cannot limit this to msvc2015 host specs only, as older projects
still might be loaded with Visual Studio 2015 causing the build to
break.
Task-number: QTBUG-49815
Change-Id: Ia120a392967319b945a9746ad489f2db0eed7156
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
The Visual Studio registry keys are stored in the 32 bit view.
Extend qt_readRegistryKey with an option that enables the caller to
choose the 32 bit or 64 bit registry view.
We now read the Visual Studio registry keys from the 32 bit registry
view even in a 64 bit build.
Adding the next Visual Studio version will become a bit easier.
Change-Id: I7300b992be6058f30a422e3f1fe0bafade6eea54
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
For some reason, the solution generator was looking for the vcproj
files in the source tree. It should look for them in the output tree
instead (suggested by Joerg Bornemann). This should handle both
in-source and out-of-source builds, and the special-case code for
handling out-of-source builds (which had a bug) can be removed.
Task-number: QTBUG-49665
Change-Id: I40b5c5907c52ffb074ccb8f297bb5924eacc1cb0
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Andy Shaw <andy.shaw@theqtcompany.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Only VcprojGenerator over-rode it; and did so with a replacement
identical to the one on the base, so there was no point to it.
Change-Id: I5b899372247809c82b1cae25817e06c5849cd10d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Commit 4bb004de94 broke the linker
options in generated Visual Studio projects.
We need to call fixLibFlags on QMAKE_LIBS and QMAKE_LIBS_PRIVATE.
Task-number: QTBUG-48936
Change-Id: I2f12bf0117d27104cd34f2f43fdeb7b948fa375e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Suffix rules are the old-fashioned way of defining implicit rules for make.
We don't need them as we generate explicit rules for all sources we build.
[ChangeLog][qmake] Makefile output no longer contains implicit
suffix rules, as all sources are built using explicit rules.
Change-Id: I4ecfa5b80c8ae33aea8730836f3baf99dd4951dd
Task-number: QTBUG-30813
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
as a side effect, this makes the extensions used for searching libraries
configurable under windows (QMAKE_LIB_EXTENSIONS).
Change-Id: I3e64304fcadbfe74d601b50a70a73180c894503e
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
first, store the library's full name in the .prl file, like we do on
unix. this is not expected to have any side effects, as QMAKE_PRL_TARGET
was entirely unused under windows so far.
then, rewrite the mingw library handling: instead of letting the linker
resolve the actual libraries, do it ourselves like we do for msvc. we
could not do that before due to the partial file names in the .prl
files: if the library didn't exist at qmake execution time, we'd have to
guess the file extension (the msvc generators never had that problem, as
they know about only one possible extension for libraries anyway).
make use of processPrlFile()'s ability to replace the reference to
the .prl file with the actual library. that way we don't need to
re-assemble the file name from pieces, which was fragile and
inefficient.
QMAKE_*_VERSION_OVERRIDE does not affect libraries coming with .prl
files any more. additionally, it is now used literally (not
numerically), and values less or equal to zero lost their special
meaning as "none" - this isn't a problem, because that's the default
anyway, and there is no need to override bogus versions from .prl files
any more.
no changelog for that, as i found no public traces of that feature
outside qtbase.
[ChangeLog][qmake][Windows] Libraries coming with .prl files can now
have non-standard file extensions and a major version of zero.
[ChangeLog][qmake][Windows][Important Behavior Changes] The .prl files
written by earlier versions of Qt cannot be used any more. This will
affect you if you depend on 3rd party libraries which come with .prl
files. Patch up QMAKE_PRL_TARGET to contain the complete file name of
the library, and replace any /LIBPATH: in QMAKE_PRL_LIBS with -L.
(the part about /LIBPATH: actually refers to the next commit.)
Change-Id: I07399341bff0609cb6db9660cbc62b141fb2ad96
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
seems pointless to tear apart the functions, on the way duplicating some
boilerplate.
Change-Id: Ide3697ca1c931e8de607ac48c21cecce4781fe13
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
this feature was added with a dubious commit message a decade ago, was
undocumented, and there are no public traces of it being used.
if i had to guess what it was meant for: to be able to consistently use
-lfoo throughout a project and centrally (e.g., in .qmake.cache) choose
to use foo<bar> (bar possibly being "d") instead. however, more explicit
methods are being used instead, including in qt itself.
Change-Id: Ic3a98dc3aec59876f26909fbf9f7aba32baa05bf
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
