Still not complete. Just grepping for static and thread_local.
Task-number: QTBUG-100486
Change-Id: I90ca14e8db3a95590ecde5f89924cf6fcc9755a3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As a drive-by, remove superfluous includes from qnetworkmanagerservice.h
and obey the coding conventions for includes in a few more places.
Change-Id: I65b68c0cef7598d06a125e97637040392d4be9ff
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
And remove their uses.
[ChangeLog][QtCore][Deprecation Notice] Deprecated QString::count()
and QByteArray::count() that take no parameters, to avoid confusion
with the algorithm overloads of the same name. They can be replaced
by size() or length() methods.
Change-Id: I6541e3235ab58cf750d89568d66d3b1d9bbd4a04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Linker response files for the MinGW and Unix makefile generators are
controlled by the variable QMAKE_LINK_OBJECT_MAX. This variable holds a
number. If the number of object files passed to the linker exceeds this
number, a linker response file containing object file paths is created.
This heuristic is extremely imprecise. It doesn't take into account the
length of object file names nor the length of $$OBJECTS_DIR.
Also, when using a static Qt, a big part of the linker command line are
libraries. A relatively small example can fail to link with "The
command line is too long" on Windows, even with the object files being
in a response file.
The MinGW makefile generator already reads the variable
QMAKE_RESPONSEFILE_THRESHOLD for compiler response files. Re-use this
variable for the linker response file of the Unix and MinGW makefile
generators.
If QMAKE_RESPONSEFILE_THRESHOLD is set, use it to determine whether to
create a response file. QMAKE_LINK_OBJECT_MAX is then ignored. The
response file contains objects and libraries.
If QMAKE_RESPONSEFILE_THRESHOLD is not set, use QMAKE_LINK_OBJECT_MAX to
determine whether to create a response file. The response file contains
only object files.
QMAKE_LINK_OBJECT_SCRIPT is used in both cases to specify a common base
name of all linker response files.
Pick-to: 6.2 6.3
Task-number: QTBUG-100559
Change-Id: I3c78354fa5ebb1a86438ec804679e0ee776c3f49
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Since this is only used by qtpaths and qmake, let's not make every
application pay the price of dynamically initializing a QString whenever
QtCore is loaded (which 100% of Qt applications do). Instead,
initializing a null pointer costs zero and is one third the size of
QString. Even the assignment in qmake and qtpaths is faster this way.
Pick-to: 6.3
Change-Id: I6fcda969a9e9427198bffffd16ce8d1eb8dc19da
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
When passing a directory to qmake, it tries to detect a .pro file in
that directory. Whenever the detection failed, qmake printed an error
message like "Access is denied." or "file to open is a directory".
Now, qmake prints an actually helpful error message:
***Cannot detect .pro file in directory '../foo'.
QMake expects the file '../foo/foo.pro' or exactly one .pro file in
the given directory.
Fixes: QTBUG-34673
Change-Id: I3d21ead247734172eee4eb68d3f9782d3ddaea52
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The C API we've used so far underlies stronger restrictions regarding
path length than QFile. Since qmake is not bootstrapped anymore, we can
use QFile.
Task-number: QTBUG-99791
Change-Id: Ic7765b0c09a8aa07c208c1b1d02efe0c54bb44f2
Reviewed-by: Dominik Holland <dominik.holland@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
In release mode, the Q_ASSERT() is a no-op, and Clang rightfully
pointed out that, in that case, the bool ok variable will be used
uninitialized.
Fix by using Q_UNREACHABLE(), which has an effect in both debug and
release builds.
Pick-to: 6.3 6.2 5.15
Change-Id: I33480aabe1c5233d1caddf9404f475ca9fcb8eaf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When a qt.conf was present, QT_HOST_* variables got a wrong default
value. For example, QT_HOST_BINS would end with /bin/bin.
We must not provide the defaults via QSettings::value(_, defaultValue).
The assignment of the default value is done in
QMakeLibraryInfo::rawLocation() separately after retrieving the value.
This amends commit 04ec14105e.
Pick-to: 6.3
Fixes: QTBUG-99656
Change-Id: I43431664e93ab40417a5432b03e7eb38ae21bad8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This is always an error, and we should not silently return an empty
string and pretend that everything is in order.
Drive-by change: Add a comment stating what createResponseFile()
returns.
Pick-to: 6.3
Change-Id: I4ee940cfac826c7ae5d15e977b692f1368ab29ea
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When having a TARGET value that contains whitespace, linking would fail
with MinGW. This was, because the function createResponseFile stitched
together a file name like this:
objectScript."Target Name".Release
The inner double quotes make the file name invalid.
Fix this by retrieving QMAKE_ORIG_TARGET with the var() method instead
of fileVar(). The latter quotes the return value if it contains
spaces.
Pick-to: 5.15 6.2 6.3
Fixes: QTBUG-99522
Change-Id: Ieb7dcf3fbbd8a75de5a9b9a6beadb2170dddf35d
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This build phase executes the qt_preprocess.mak makefile from Xcode
and should be triggered whenever any input of any rule in this makefile
is out of date. It was not triggered when a file that's referenced in
a .qrc file was changed.
The Xcode project lacks those files as rule input, but the makefile
itself has its inputs correctly set up, and can be triggered always.
Pick-to: 6.2 5.15
Fixes: QTBUG-94995
Change-Id: Ida1349039bd6f23a300a610ecbde96f7cd35edb6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Fixes
qtbase\qmake\generators\makefiledeps.cpp(985): warning C4267: '+=': conversion from 'size_t' to 'int', possible loss of data
qtbase\qmake\generators\makefiledeps.cpp(986): warning C4267: '+=': conversion from 'size_t' to 'int', possible loss of data
Pick-to: 6.2
Change-Id: I7c6b4f36dc383db420c10d674666d58dbf29d2dd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Like Q_NAMESPACE_EXPORT for Q_NAMESPACE, this variant of Q_GADGET
allows passing an export macro. This is useful to avoid exporting the
whole class just to get the staticMetaObject hidden therein exported.
Before anyone asks: No, we don't need Q_OBJECT_EXPORT, because QObject
subclasses, being polymorphic, always need to have a class-level
export macro (to export their vtable), but while that technique also
works for value classes (the Q_GADGET audience), it is not desirable
for them, because it makes inline functions exported in Windows debug
builds, which is not what we want, because it needlessly restricts
what you can to with the inline functions (e.g. remove).
[ChangeLog][QtCore] Added the Q_GADGET_EXPORT macro, which is like
Q_GADGET, but allows passing an export macro (like Q_NAMESPACE_EXPORT
for Q_NAMESPACE).
Fixes: QTBUG-55458
Change-Id: I546297de1e8aa45d83381991bcd3fbca61e1eef0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
De-unroll the loop over the "interesting" keyword ignore comments by
using the existing array of their names. Replace magic numbers by
strlen() calls. Use local starts_with() instead of strncmp() when
comparing with fixed-size constant string literals, to avoid repeating
the fixed string's lengths for the third argument of strncmp().
Task-number: QTBUG-55458
Change-Id: If458aced382948fb719d984702857fb2171c87ee
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Use a local enum to enumerate the different "interesting" keywords.
Task-number: QTBUG-55458
Change-Id: I30a6336072d3184b720d8c016f199572dba87a81
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We have some special handling in qt_windows.h,
use it instead of the original windows.h
Change-Id: I12fa45b09d3f2aad355573dce45861d7d28e1d77
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This allows us to present 'qmake' in the tool-related section of the
configure summary.
Change-Id: I897dec23cb0608706ec01d9b91283dbce92b293f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
[ChangeLog][qt.conf] The key Paths/Qml2Imports has been renamed to
Paths/QmlImports. For backwards-compatibility, Paths/Qml2Imports is
still accepted and acts as default value for when Paths/QmlImports is
not present.
Fixes: QTBUG-98335
Change-Id: If7ffedd281eb8a87e8ab1a2b69a823e615c33541
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
In addition, added the missing warninglimit
entry to a few doc configs.
Change-Id: I51b9d2ad66123a2a9673a3b42870662641375e6b
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
...which represents the version of the MSVC platform toolset.
This variable is used to set the platform toolset version in .vcxproj
files. Before, the platform toolset version was determined in qmake's
C++ code. Now, it's set next to where MSVC_VER is set in common mkspecs
.conf files. This will simplify supporting new Visual Studio versions
in the future.
Change-Id: If78c921f93c6378829746d617c7e7d312174257e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
Introduce a new macro qt_internal_return_unless_building_tools which
simply calls return() if tools are not built. This macro is supposed to
be called after qt_internal_add_tool().
Using this macro avoids having to special-case code for when
qt_internal_add_tool() creates imported targets in cross-builds.
Adjust pro2cmake accordingly.
Task-number: QTBUG-85084
Change-Id: I9e1c455c29535dd8c318efa890ebd739c42effc1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QT_VERSION is now at least QT_VERSION_CHECK(6, 3, 0), so remove all
checks against Qt 6.0.0 or earlier. They are superfluous. Tidied up in
some places in the process, particularly #include order.
Change-Id: I2636b2fd13be5b976f5b043ef2f8cddc038a72a4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
customFilters defined in .qdocconf are not supported anymore by Qt
Assistant since Qt 5.13. Therefore remove them from all .qdocconf files,
also to avoid cargo-culting them to new help modules.
Task-number: QTBUG-95987
Change-Id: I664391460637d2e859348da0338e1a4a3ee9f570
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
By the time of Qt 6.2 release all new apps targeting Play store must
target API level 30 (Android 11) or above (starting in 08/2021 for
new apps and 11/2021 for existing apps' updates).
Pick-to: 6.2 5.15
Task-number: QTBUG-94451
Change-Id: Id7fa2fd62899a7259e365c917292c6c3ac0d2b0d
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Make it possible to select the C17/C18 standard with
CONFIG += c17
or
CONFIG += c18
Pick-to: 6.2 5.15
Fixes: QTBUG-96026
Change-Id: I719d22366c3efda009118d58ead173a25ed285c0
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
The format was renamed in 27db9e458c.
Pick-to: 6.2
Change-Id: I53975c7467d8768dc9dc9ac2d89c42eefa12e22f
Reviewed-by: Mårten Nordheim <marten.nordheim@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>
- Replaced # with / after link prefix "Qt for macOS"
- added definite article
- punctuation issue
- Added prefix "Qt for macOS/" to one link, and
changed "macOS Version Dependencies" to "Supported Versions"
Fixes: QTBUG-90662
Change-Id: Ib2e48ee477e8d34fece64d6dea1f86fe73f09478
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This prevents us from first reserve()ing Prealloc elements, and then
possibly reserve()ing a larger number, which leaves the first bucket
list's memory unused.
Consequently, deprecate reserve().
Change-Id: Ifc0a5a021097f4589557e7b5e45d9d0892797ade
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In a Qt build that was configured with INSTALL_MKSPECSDIR set to
something different than INSTALL_DATADIR, the qmake property
QT_HOST_DATA was wrong. Consequently, mkspecs could not be loaded,
rendering qmake dysfunctional.
The reason was that we considered every QT_HOST_xxx property to have the
same value as QT_INSTALL_xxx in a non-cross build.
This is not true for QT_HOST_DATA, because users might want to set
INSTALL_DATADIR to "foo" but INSTALL_MKSPECSDIR to "bar/mkspecs".
Move the unused determination of the host data dir to the QtLibraryInfo
lib and handle QT_HOST_DATA specially.
Fixes: QTBUG-94591
Pick-to: 6.2
Change-Id: I2c44cda8405ff1d14391254fcd1d9b1361cb5855
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
error LNK2038: mismatch detected for 'RuntimeLibrary': value
'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'.
Change-Id: I1422bdc680a066f0736c3e28cc6beafd2461db88
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
After the discussion we concluded that QT_HOST_PREFIX should not
completely replicate the QT_INSTALL_PREFIX behavior.
So this patch implements the following logic if qt.conf is provided:
1. Prefix is not set
a. If HostPrefix is not specified, then QT_HOST_PREFIX will be set
to the folder containing qt.conf.
b. If HostPrefix is specified and is relative, then QT_HOST_PREFIX
will be relative to the folder containing qt.conf.
2. Prefix is set
a. If HostPrefix is not specified, then QT_HOST_PREFIX will have
the Prefix value.
b. If HostPrefix is specified and is relative, then QT_HOST_PREFIX
will be relative to the folder containing the qt.conf.
The logic might change in a future commit to use the current application
directory instead of qt.conf path, since the use of qt.conf is dictated
by the bootstrap library and this is no longer the case.
Fixes: QTBUG-93707
Change-Id: I5460c97c45924bb8e0c95493afdb9585994c5f28
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To not scare sanitizers and their users.
Change-Id: I51de5d6a5a358b3cf1355aeb6cc826a6ac021243
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In a cross built Qt, for example Qt for Android, calling "qmake -spec
android-clang" led to an error message:
"Could not find qmake spec '-qtconf'."
This happened, because:
- the qmake in Qt for Android is a wrapper script that calls
"qmake -qtconf qt_target.conf -spec android-clang"
- the first stage of command line argument handling in qmake garbled the
call to "qmake -spec -qtconf qt_target.conf android-clang"
We do not modify the order of arguments anymore.
Instead, we skip the "-qtconf <file>" arguments in the first argument
handling stage that is supposed to determine qmake's modus
operandi (like -project or -query).
In addition, we need to fix the assignment of
QLibraryInfoPrivate::qtconfManualPath which was only done if
QMakeGlobals::addCommandLineArguments returned ArgumentsOk. However,
this function returns ArgumentUnknown, if it encounters an argument it
cannot handle - like the project name.
Now, we assign QLibraryInfoPrivate::qtconfManualPath if there was no
error detected.
Document the return values of addCommandLineArguments.
This amends commit 661b586a69.
Pick-to: 6.1 6.0
Fixes: QTBUG-93079
Task-number: QTBUG-85136
Change-Id: I12ec25b17d64c00be2a3904b7c4a975b781500a0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Other manuals have a 'Getting started' section too. Better to qualify
it further, so that searching in the Index of Qt Creator Help mode or
Qt Assistant allows to differentiate between the different products.
Pick-to: 6.1
Change-Id: I7cfdba3c3567bdf49d3fe34307576f88c9f20126
Reviewed-by: Paul Wicking <paul.wicking@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>
Add the option argument INSTALL_VERSIONED_LINK to qt_internal_add_tool
and qt_internal_add_app. For tools/apps with this argument we create an
install rule that creates a versioned hard link. For example, for
bin/qmake we create bin/qmake6.
Note that this only applies to prefix builds.
Apply this argument to qmake.
The qt_internal_add_app change is necessary for qtdiag and in qttools.
Task-number: QTBUG-89170
Change-Id: Id32d6055544c475166f4d854aaeb6292fbb5fbb5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit c19d957f45fa27f61b5ecc566f8dbc19f12a44c3)
Fix the C4715 warning for 'hostToTargetPathEnum' by marking the qFatal()
branch as unreachable.
Change-Id: Id065daaffd865e85985b1a8e0ac2eba4a2ff0b1c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Exporting QLibraryInfo internals allows to reuse settings in
qmake/qtpath without having to keep its own instance.
Also there is no need to check setting groups in QLibraryInfo
except the 'Paths' group, since this logic belongs to qmake/qtpaths
only.
Change-Id: If762defba025ad7f7489f8a86ef5768a8628bd2f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the ability to select a standard and json output formats of
the Qt properties. This patch also improves the encapsulation of
QMakeProperty.
Change-Id: Ib1d232be1b430ed8456ce65cc98141282e4c3f7f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some qmake sources could be reused by other tools. It makes sense to
move such sources to the object library, to avoid additional compilation
steps and to simplify the reuse of sources.
Change-Id: I9d7bb7624019149d34d29e4b269b4f26b8aec7a4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Now that we're not actually using qmakeconfig.cpp anymore, we can remove
it together with all qmake-related information that was written into
qconfig.cpp.
This also moves the qtConfEntries array back to qlibraryinfo.cpp.
Change-Id: I5e57d8c55613332cc3e57b11df4398d46aed259b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Those have fixed values.
Change-Id: I7f1ba8036f43413d3c805f4b419ae79e037343fb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Now, that qmake depends on QtCore, we can just ask QLibraryInfo for the
prefix instead of calculating it from QT_CONFIGURE_RELATIVE_PREFIX_PATH.
Remove that define.
Change-Id: I14be298a9d08abf33299e4cdbac55e91af318397
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is not configurable and doesn't have to be in the generated
q[make]config.cpp files.
Change-Id: If294d735800a3b5c6b3e269abdd86df401cf4864
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a conditional build of the qmake.
Task-number: QTBUG-89369
Change-Id: I8d7968ffb20ea31df2f85fff055e0d131ed06a36
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When packaging different Qt versions for Linux distributions (or any
distribution with a common bin dir), Qt tools cannot be installed to
/usr/bin, because the executable names of the different Qt versions
clash.
To solve this conflict, our recommendation is to install Qt's tools to
/usr/lib/qt6/bin and to create versioned symlinks to user-facing tools
in /usr/bin.
User-facing tools are tools that are supposed to be started manually by
the user. They are marked in Qt's build system. Distro package
maintainers can now configure with
-DCMAKE_INSTALL_PREFIX=/usr
-DINSTALL_BINDIR=/usr/lib/qt6/bin
-DINSTALL_PUBLICBINDIR=/usr/bin
and will find a file called user_facing_tool_links.txt in the build
directory after the cmake run. Nothing will be installed to
INSTALL_PUBLICBINDIR.
Each line of user_facing_tool_links.txt consists of the installation
path of a user-facing application followed by a space and the versioned
link name in INSTALL_PUBLICBINDIR.
Example content:
/usr/lib/qt6/bin/qmake /usr/bin/qmake6
To actually create the versioned symlinks, the content of this file can
be fed to ln like this:
xargs ln -s < build-dir/user_facing_tool_links.txt
Or the package maintainer may decide to do something completely
different as suits their needs.
This patch adds the USER_FACING argument to qt_internal_add_tool to mark
tools as user-facing. In addition, every Qt created by
qt_internal_add_app is treated as user-facing.
The only tool this patch marks as user-facing in qtbase is qmake.
Pick-to: 6.1
Fixes: QTBUG-89170
Change-Id: I52673b1c8d40f40f56a74203065553115e2c4de5
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
QMakeLibraryInfo uses external data to produce paths. This causes
issues when trying to use it out of the existing qmake environment.
Add data fields that contain the path to the binary that uses
QMakeLibraryInfo and manually specified qtconf.
Task-number: QTBUG-75870
Change-Id: Ic6fa274ede3a9287826ff66c79f155b10d0d455c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Since the QT_CONFIGURE_HOSTBINDIR_TO_HOSTPREFIX_PATH and
QT_CONFIGURE_HOSTBINDIR_TO_EXTPREFIX_PATH definitions keep the same
value in modern CMake build, no need to have special handling in cases
where these values are used in qmake. Also it will be useful to
specify the relative path to the prefix directory from the directories
different of 'bin' when use QMakeLibraryInfo.
Task-number: QTBUG-75870
Change-Id: I5a777001eb334dcf05e22853a514d4257352d59b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
QT_CONFIGURE_CROSSBUILD is always '0', so it's not necessary to keep
conditional compilation in QMakeLibraryInfo.
Also the QT_CONFIGURE_SYSROOTIFY_PREFIX definition is never used
in the project.
Task-number: QTBUG-75870
Change-Id: I1fe42dce40fddc6a72254736883f93aa4727f6b3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Move the qmake-specific logic of the QLibraryInfo class to
qmake internals. 'qconfig.cpp.in' now stores information about
the library info entries to keep them consistent between qmake
and the Core library. qmake requires specific features enabled
in the Core library, so building qmake will be skipped if the
features are not enabled.
All flags directly related to the qmake have been removed from
Core lib.
Remove all bootstrap related sections from qmake CMakeLists.txt
Task-number: QTBUG-89369
Change-Id: I26de157d3bfd4a5526699296e9d46e1c180b89ae
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Since commit 4933a5f892, CONFIG contains C++17 by default.
Change-Id: I1033c256242c03d79a643c12a63d17eb9f4c705f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This will be used to access host tools that are installed in
${prefix}/libexec instead of ${prefix}/bin.
Pick-to: 6.1
Change-Id: I36c4b5736330f8229d267a117c65d55cd5e12758
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Keep the c++2a feature, but make it an alias for compatibility
purposes.
Pick-to: 6.1
Change-Id: I6f153109be84659806f1b7a57a88a187875166d8
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@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>
The "2" is meaningless. We retain the old name as alias for source
compatibility, but we don't document it anymore.
Task-number: QTBUG-85064
Change-Id: Id10d58f6d39a0faaec042304b374ae6b23469362
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
The QT_BUILD_QMAKE_BOOTSTRAP and QT_BUILD_QMAKE_LIBRARY definitions
are never defined in the project since migrating to CMake build.
Change-Id: I7108c92387005a2fde6ebdb2d74843e3efc6413e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To enable the current Qt version to use a qt.conf that is independent
from the previous version, a file named 'qt<major-version>.conf' is
searched for first. If this file does not exist, a file with the
name 'qt.conf' is searched for.
Task-number: QTBUG-88635
Change-Id: If75b63f72a7bdbdf1de7729ea4ecb00810b58d12
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Those serve no purpose anymore, now that the .pro files are gone.
Task-number: QTBUG-88742
Change-Id: I39943327b8c9871785b58e9973e4e7602371793e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This leaves a very simple script that delegates the heavy configure work
to a CMake script.
This also removes the Makefile templates that were used for
bootstrapping qmake.
Task-number: QTBUG-88742
Change-Id: Iab9c477e0bb611d680bda2cf8aaa7ad88356a8d1
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
We must not pass null pointers to memcpy.
Pick-to: 6.0
Fixes: QTBUG-88780
Change-Id: Ic1d77b4672310a3f6d0d4fbee5f2889e3e4d219d
Reviewed-by: Lars Knoll <lars.knoll@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>
Play Store now accept only app with target
SDK version set to 29 or above
Pick-to: 6.0
Change-Id: If38f20c88fd6b0e6f29939cdf3d2eb793c0e1489
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Copy back changes to qmake internals that were done in qttools.
This makes it easier to keep the qmakelib copies in sync.
The code guarded by PROEVALUATOR_CUMULATIVE is not used by qmake itself,
but only by lupdate and Qt Creator. It seems to be sensible to have the
same behavior with regards to feature file evaluation in both
projects. It was originally introduced in qttools for QTBUG-62478.
The change regarding QT_BOOTSTRAPPED is safe, because the 'process'
feature is available and off in the boostrapped case.
Change-Id: I030ca8b093c017040a9ff9f4bb09a7cca4aa8964
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This function may take a wildcard expression, not a general regular
expression.
Pick-to: 5.15
Change-Id: Ia7ba3bac47c310bc035620583b9d2102fdc5ffb0
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@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>
*Not* using /permissive- exposes Qt and client apps to interesting
bugs and/or build failures, (e.g. QTBUG-87225, or
19b5520abf). We demand strict
conformance by any other compiler, it's time to demand it from
MSVC too.
The Windows headers themselves are clean starting from the
Windows Fall Creators SDK (10.0.16299.0), and moreover Qt 6 will
drop WinRT; therefore, the comment in the mkspecs does not apply
any more.
Since /permissive- implies /Zc:referenceBinding, drop that
option. The other implied options are set on MSVC < 2017,
but I leave them in to avoid tinkering with the fragile lists
of C/C++ flags.
Rename the CMake internal helper function to better describe
what it does.
Fixes: QTBUG-85633
Fixes: QTBUG-85637
Fixes: QTBUG-85635
Fixes: QTBUG-88244
Change-Id: Ie03fddb61aa066fdc14b7231c22e7108b4a02fbb
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
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>
ANDROID_ABIS should be used instead of ANDROID_TARGET_ARCH.
Fixes: QTBUG-81866
Pick-to: 5.15
Change-Id: I6dc9e0cd2a19bea8864e3ab4174bd609c0aad4dc
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
qmake currently doesn't have a doc target in CMake. In qmake builds, the
doc target is in qtbase/ (not in qtbase/qmake). This patch mimics the
mechanic used in QDoc, and adds this as a special case (as the project
file doesn't contain the doc target).
Fixes: QTBUG-87868
Change-Id: Ib1ca249465c5df2f22ba73084c680781e595c30a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Detect the case where the first argument is -qtconf <file> and ignore
that for the -install argument.
Task-number: QTBUG-87801
Change-Id: If6822ee3ebef99de645aee8d110ebdcb13fb2da2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
