This requires explicitly marking constexpr if conditions to fix C4127
issues:
qtbase/src/corelib/text/qstringbuilder.h(112):
error C2220: the following warning is treated as an error
qtbase/src/corelib/text/qstringbuilder.h(112):
warning C4127: conditional expression is constant
qtbase/src/corelib/text/qstringbuilder.h(112):
note: consider using 'if constexpr' statement instead
Change-Id: I9787fb37099f811c52f93c94c9edb4da8aafdfe5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The gc_sections linker flag was recently wrapped in a
$<CXX_COMPILER_ID> genex to prevent adding it the command line when
using an incompatible compiler.
This causes an issue when generating .pc pkg-config files because
$<CXX_COMPILER_ID> can't be used in the output of a file(GENERATE)
call.
Record the flag in a global property, both the genex-wrapped and bare
forms, so that we can perform a string replacement when generating
the pkg-config file to remove the genex wrapping.
This is not perfect, in the sense that consumers of the .pc file
might get the wrong flag if using an incompatible compiler, but
it's better than outright failing the Qt build.
Distros will be expected to patch the .pc files if necessary.
Note the issue does not usually happen for regular Qt builds because
gc_sections is only enabled automatically for static builds, but for
static builds we don't currently generate .pc files.
So the issue only happens in shared Qt builds where the gc_sections
feature is enabled manually.
Amends a2b6c2f343
Pick-to: 6.5 6.6
Fixes: QTBUG-115243
Change-Id: I3f6bdf86c24ee90b6da04994e458b438cc41fc7a
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Qt 6 requires /utf-8 for user-projects by default, but allows users to
opt-out (cf. 0cdcbb40a1), so we shouldn't
use non-ASCII characters in public headers.
Amends 97f643faee.
Fixes: QTBUG-115229
Pick-to: 6.6 6.5
Change-Id: Ieb93ea9f3526e7bcc2e5aeffb5e69c68d10db792
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Standalone test projects have the following condition in the
beginning of their project:
if(NOT QT_BUILD_STANDALONE_TESTS AND NOT QT_BUILDING_QT)
find_package(Qt6BuildInternals COMPONENT STANDALONE_TEST)
endif()
When configuring the project the first time, QT_BUILDING_QT is not
set, find_package is called, configuration succeeds.
But because standalone projects implicitly include QtSetup.cmake,
that file sets the QT_BUILDING_QT cache var to true, and upon test
reconfiguration, cmake errors out with:
Unknown CMake command "qt_internal_add_test"
or similar.
This happens because QT_BUILDING_QT is true on the second
reconfiguration and the find_package mentioned above is not executed
anymore, leading to unknown internal command errors.
Set a new QT_INTERNAL_IS_STANDALONE_TEST variable when we detect
a standalone test and check for its value in QtSetup so we don't
set QT_BUILDING_QT to TRUE anymore.
Adjust a few code locations where QT_BUILDING_QT being false might
trigger different behavior for standalone tests.
Task-number: QTBUG-93020
Change-Id: I5413b9f37653225175a1006f7626e023045b5979
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Bring back & update comment on -Za, which was removed
in 8bf60251 (in turn reverted in commit 2dcc3059).
For the details on -Za vs -permissive, see
https://devblogs.microsoft.com/cppblog/permissive-switch/:
and the official Microsoft documentation.
This amends 2dcc30592b.
Change-Id: Ibeb135218dd0a17eddf821ad79246906993c586f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Cmake supports finding OpenGL, even if there is no GLX (for glvnd) or
old-style libGL. This change keeps old behavior, but in case, if
X11-related OpenGL libraries cannot be found on Linux, it adds logic
to check for (and link with) libOpenGL, if it is present.
[ChangeLog][QtGui] Allow OpenGL to be found on X11-less Linux systems
(using libOpenGL)
Change-Id: Iccfeba83292a14081544c64ea8ce24fb52d1ee2f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We should not automatically enable vcpkg as soon as we find it on the
system. With this change, we disable the automatic
detection/integration.
[ChangeLog][configure] Vcpkg detection/integration is now disabled by
default, and it can be enabled by either passing `-vcpkg` to the
configure script, or by passing `-DQT_USE_VCPKG=ON` to cmake.
Change-Id: I4f098db670f11373064c071f1c3204e2e183d3db
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Just a minor change, so that it's clear that we are setting the supplied
toolchain as the VCPKG_CHAINLOAD_TOOLCHAIN_FILE.
Change-Id: I10b35f04e7ad684015062066f67117ce4a964c1c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In order to use multiple toolchain, e.g., when we are cross compiling,
we need to load the detect, and load vcpkg's toolchain after our
toolchain file.
Change-Id: I7f3374363f725a634356788e22ac21835505c4b0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This commit provides a minimal API for capturing a graphics
frame, save it and replay it later for debugging. The intention
here is to provide the basic need for future work to allow capturing
through tooling or programmatically from code. This API is
intended to be cross-platform by using Metal Capture Manager on
Apple devices and RenderDoc C++ API everywhere else.
Task-number: QTBUG-114067
Change-Id: If72d92bdef5e5985a0ec2e85e97fd1182da3c53c
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
CMake find modules of third-party libraries may create dependency cycles
in their imported library targets. For example, Conan's Vulkan::Vulkan
is such a candidate.
Prevent an infinite loop when generating .pri files for Qt modules that
link against such targets.
Pick-to: 6.5 6.6
Fixes: QTBUG-95569
Change-Id: I09b4a281930f7c6ce5e8c716fe0ab91e2453a24a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Interface libraries don't build anything, commands that belong them
might not run if nothing depends on an interface library. We still need
to make sure that we run syncqt for interface libraries.
Add '_sync_headers' for interface libraries to "ALL" explictily.
Amends a8cf976ce6
Fixes: QTBUG-115101
Pick-to: 6.5 6.6
Change-Id: I24b34574fdc3060e3a60886620dbe5c1b526f1a7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
VCPKG by default does static builds when building for Android.
This is at odds with the bundling-concept, so it should not be done
unconditionally.
Since we don't necessarily have the WrapOpenSSL target on-hand, let's
just do a file-exists test for the one of the paths we would include.
Pick-to: 6.6 6.5
Change-Id: I3693354308d5168d8a9c3d1659bfa51540114b7f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
It's a bit excessive to warn every developer about this, especially if
they are using non-Xcode generators; besides, we are already generating
a bundle identifier if it is missing anyway.
Pick-to: 6.5 6.6
Change-Id: Ib11ad51a0e516e0ea61ad2f7bf499b846bc0b792
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We shouldn't try to promote tool targets if they were not created
when Qt6FooTools_FOUND is FALSE due to missing dependencies and
Qt6FooToolsTargets.cmake is not included.
Add a check for Qt6FooTools_FOUND to prevent errors like:
CMake Error at lib/cmake/Qt6/QtPublicTargetHelpers.cmake:257
(get_property):
get_property could not find TARGET Qt6::qtprotobufgen. Perhaps it
has not yet been created.
Pick-to: 6.5 6.6
Change-Id: Ie26db637d4d8ef682a0ada5ea36ef0e8ceced008
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This environment variable is used by vcpkg to avoid having to pass
the --triplet argument on the command line on every vcpkg invocation
and shouldn't influence the triplet used during build. In fact,
the vcpkg.cmake toolchain will automatically attempt to deduce the
target triplet if we don't define this beforehand.
As a replacement, read from the QT_VCPKG_TARGET_TRIPLET environment
variable. It has the QT_ prefix to make it clear this is not a
standard vcpkg environment variable.
[ChangeLog][Build System] Qt no longer uses the VCPKG_DEFAULT_TRIPLET
environment variable to deduce target triplet. By default we let
vcpkg's toolchain file automatically deduce the triplet to use.
The new QT_VCPKG_TARGET_TRIPLET environment variable can be used
instead, or pass -DVCPKG_TARGET_TRIPLET=<triplet> to CMake.
Pick-to: 6.6
Change-Id: Idc6cbd52a68578d1762ca175c4973355409688ac
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Amend 9d5a8162a5, after which building Qt
for Android locally required an OPENSSL_ROOT_DIR variable to be set.
Instead of making it harder for everyone to build Qt for Android (even
if no intention to work on or test network code locally), downgrade the
fatal error to a warning.
Pick-to: 6.6 6.5
Change-Id: I6f2176a40663cc9f55aa3066af78499af1f20894
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Surprisingly, CMake copy/install empty directories when `file` or
`install` are used with `FILES_MATCHING PATTERN` argument.
In order to avoid this, we can exclude the empty directories using a
PATTERN EXCLUDE argument.
Pick-to: 6.5 6.6
Change-Id: I17a22f9b9e317bc4a66cee3df39815659ddb4c04
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Homebrew offers a formula for `vulkan-headers`, which does not include
the MoltenVK headers. MoltenVK does include the vulkan headers, but if
someone passes the vulkan-headers path to CMAKE_PREFIX_PATH, then our
module cannot pick up the MoltenVK headers. Brew's MoltenVK
installation is a bit odd as well, as in, one needs to point the
CMAKE_PREFIX_PATH to `HOMEBREW_PREFIX/molten-vk/libexec/` instead of
the directory head.
Pick-to: 6.6
Change-Id: I933faeb16b3f54597e3a0af0af584d79b3c0a344
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We want syncqt to be built optimized by default. The current approach
set the default build type for the external projects and optimized
flags for the non-configure-time syncqt build. The problem is that
syncqt still have compiler flags littered by either the Qt configuration
type or the system defaults that are applicable for RelWithDebugInfo
configuration(the default one we chose for syncqt).
This patch makes sure that we cleanup all compiler flags from any
optimizations and apply optimized flags for all configurations. Also
we discard '/RTC1' flag if it's set. Configure time executables now
respect the language related flags that are set in the project and
adjust the flags passed to try_compile.
For linker flags we should use those that are applicable for the
preferred build type. Since syncqt is built in RelWithDebugInfo
by default we should replace linker flags in all configs with
those are used for RelWithDebugInfo configuration.
Fixes: QTBUG-114925
Pick-to: 6.5 6.6
Change-Id: I782f81a36f5ef7ee4d342ce8ac6c217cb2552f3b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The check_language macro spawns a new cmake subprocess to detect
availability of a language. We use that to detect availability of
the Objective-C/C++ languages when targeting Apple platforms.
That's problematic because the parent process CFLAGS / LDFLAGS env
vars influences the result of the subprocess compiler detection,
and in some cases that can fail the detection.
An example of that is passing iOS specific flags which then get
mixed with the default macOS flags added by CMake, resulting in
a linker failure.
Instead of using check_language, explicitly enable the Objective-C
and C++ languages when targeting Apple platforms because we know
that we need them for compiling Qt.
This avoids the issue because enable_language is not spawning a
separate cmake sub-process and thus passes more information to the
underlying try_compile project to ensure a successful check.
The change also means that CMake will error out earlier in case if the
Objective-C compiler is not found, which was not the case before.
Pick-to: 6.5 6.6
Fixes: QTBUG-114470
Change-Id: I1a16c1e5828dfe10b2d7da27cc9a8c787517ab8e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
I added the ability to use `-no-unity-build`, and included the
batch size in the config.summary as well. In addition, qt_feature is not
being used for `-unity-build` anymore.
Pick-to: 6.5 6.6
Change-Id: I4a10e03d3505336d2256280ed2854ec0425df47f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Explicitly check that at least CMake 3.21 is used when building Qt or
when using Qt in a project.
This only affects macOS and iOS builds.
We check for 3.21 instead of 3.21.1 as described in the documentation
to avoid an error like:
Policy VERSION range "3.21.1...3.21" specifies a larger minimum than
maximum.
Until the technical limitation is addressed, if someone does end up
using 3.21.1, another existing check for "unsuitable" cmake versions
(as opposed to minimum required) will let them know they should use
something newer.
Amends 1cf3295cef321c9a587af2f2de7740c0cd3ca743.
Pick-to: 6.6
Fixes: QTBUG-114869
Change-Id: I2a479baaa63cfbe23af187cf0796e1c00042692b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Newer msvc gives C4309 warning for 'initializing':
truncation of constant value
Warning would go away if we had 'enum foo: unsigned'.
Disable the warning for problematic enums is not enough
as it also complains about headers coming from windows sdk
like:
C:\Program Files (x86)\Windows
Kits\10\include\10.0.22621.0\shared\wtypesbase.h(395): warning C4309:
'initializing': truncation of constant value
Note 10.0.22621.0 is the latest sdk already.
Do not disable language extensions for header clean target.
This reverts commit 8bf602518d
Task-number: COIN-1059
Fixes: QTBUG-114931
Pick-to: 6.6
Change-Id: Ifc3883f88a6bd52794a37dc640eca99c158a40e0
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
The syncqt tool was originally designed to run at build time, as a
part of dependency chain of Qt modules. This works well unless we need
the code model of the Qt project in IDE, since Qt source code actively
uses header aliases, and creating them at build time breaks the code
model until the initial build is done. So we made syncqt the configure
time tool to not break the developer experience.
It's more likely that developers build Qt using command line or don't
need the code model before the first build. So running the tool at
configure time should be optional.
QT_SYNC_HEADERS_AT_CONFIGURE_TIME switches the "mode" of the syncqt
tool from build time tool to the configure time tool. Without the
option enabled build procedure runs all the syncing targets at build
time only. The exception are the developer builds, if the
'-developer-build' option is enabled, QT_SYNC_HEADERS_AT_CONFIGURE_TIME
is set to TRUE by default. This gives better development experience for
the developers that don't use the code model in their IDE or don't
require it before the first build is finished. Also this build time
mode is preferred for the CI or similar build procedures where code
model is not required at all.
By default, the option initialized from the
QT_INTERNAL_CONFIGURE_FROM_IDE CMake variable.
TODO: The option is forced to TRUE for the static Ninja Multi-Config
builds. See QTBUG-113974 for details.
[ChangeLog][Build System] When building Qt from sources, syncqt and Qt
header files are now created at build time, not configure time. This
should speed up the configuration step. You can set the CMake variable
QT_CONFIGURE_TIME_SYNC_HEADERS to ON to use the previous behavior,
though. The old behavior is also preserved if cmake/configure is run
from inside an IDE - Qt Creator, Visual Studio Code, and CLion are
currently detected.
Task-number: QTBUG-111163
Task-number: QTBUG-109792
Pick-to: 6.6
Change-Id: Ib61bda9546e58492be874a8591c37e100313d02c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Vcpkg detection is enabled by default, but we did not have a flag to
disable it, and it was not showing up in config.summary either. By
adding a -vcpkg flag, we get to use `-no-vcpkg` when necessary, as well
as adding an entry to config summary indicating whether vcpkg is in use
or not. Besides `-no-vcpkg`, one can pass `-DQT_USE_VCPKG=OFF` to cmake
command in order to disable the automatic vcpkg detection/integration.
[ChangeLog][configure] vcpkg detection, and integration can be disabled
by passing the -no-vcpkg flag to the configure command, or by passing
`-DQT_USE_VCPKG=OFF` to the cmake command.
Pick-to: 6.6
Change-Id: Ide8da70a7b473ec23995104d162356e75e6d1240
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It should be possible to build a test in any configuration
by building Qt in that configuration, and then building
the test with qt-standalone-test.
Not all Qt configurations will be able to run all tests,
(due to exec() calls and similar) but that's OK - some
tests don't have exec() calls, and we want to be able
to run tests for a given configuration to figure out
how well it works.
On CI we want to use batching and asyncify, so it makes
sense to tie usage of asyncify to batching.
Pick-to: 6.6
Change-Id: I05553d250a45c1831f43dc71a43ef02d01d70535
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
The new argument would allow bundling the prebuilt OpenSSL libs
into the test apk so that SSL can actually run. It expects the CMake
argument OPENSSL_ROOT_DIR to be set ( we set that in Coin configs).
Task-number: QTBUG-110025
Pick-to: 6.6 6.5
Change-Id: I4c82796635ca89f5511255ae26182f41a504b026
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The export name is now ${TARGET_NAME}Entry. This can also be overridden
by using QT_WASM_EXPORT_NAME, both in CMake and qmake
Change-Id: I59c97ae6e22f0b2720716e9d7eff7b6b13d37ab5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Set `QT_COMMAND_LINE_PARSER_NO_GUI_MESSAGE_BOXES` before trying to run
qt tools for correctness. This is to suppress QCommandLinerParser from
showing a message box when console is not available.
Pick-to: 6.5.2 6.5 6.6
Task-number: QTBUG-114530
Change-Id: Ib3d264a799a5da1f620d2bebe55539bafc43da0f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Spack, like VcPkg, sets the `CMAKE_FIND_FRAMEWORK` to `LAST`, as a
result, similar to VcPkg, when Spack is used, FindGSSAPI opts for
`gssapi_krb5` which is not what we want. By dropping the `gssapi_krb5`
from the list of alternative names we can resolve this without much
tinkering with internals of these package managers.
Pick-to: 6.5 6.6
Fixes: QTBUG-114537
Change-Id: If517c409511f58e3bed78316a2030393dc249a40
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
TestCocoon is not maintained anymore, and the -testcocoon configure
option of Qt didn't do anything useful since Qt 6.0.0.
Remove the option. It's possible to create an instrumented build by
using dedicated CMake toolchain files as described in the documentation
of Squish Coco (TestCocoon's replacement).
Fixes: QTBUG-88316
Change-Id: I8a565cdd288aca9208f48138d2b663802cc0de90
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
CMP0099 changes the way of LINK_ONLY genex works. With CMP0099 set to
OLD LINK_ONLY genex only links the exact library binary/archive without
propagating other interface options from the target. This feature was
exploited by PlatformXInternal targets to avoid propagating of their
linker options. Nowadays when CMP0099 is forced to NEW by Qt scripts,
including user-facing, we cannot rely on LINK_ONLY genex.
Introduce _qt_is_internal_target property that is set for all Qt
executables and explicitly limits the propagation of the linker
options from PlatformXInternal targets.
Pick-to: 6.5 6.6
Fixes: QTBUG-113641
Change-Id: I3a0ecddb65886e435073feb24c1b47035130ba70
Reviewed-by: Alexandru Croitor (OOO) <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Some of our tools don't have the `-h`, or `-v` flag, or it could be
that the `-v` flag also prints the entire `--help` as well, e.g.,
`androiddeployqt`. When running in Jenkins, this may lead to a message
box being shown and consequently stopping the build. By customizing the
flag per tool, and limiting the TRY_RUN to tools that support `-v` or
`--version`, we can avoid this.
Also removed TRY_RUN from `macdeployqt` which doesn't need it anyway.
Amend 41b32cd2c4
Pick-to: 6.5.2 6.5 6.6
Fixes: QTBUG-114530
Change-Id: I78e3344d2553c0050c285ae86f2310bd373c6c57
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Fix the argument prefix that is used in the cmake_parse_arguments call.
Pick-to: 6.5 6.6
Change-Id: Ie02bdf7d2769ce084b0d173c1e8152ca6fc4fe53
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If flags use CMake scopes that propagate them to user libraries, it may
lead to an issue, if user projects are built using different compiler.
We need to guard these flags to make sure that they only will apply to
respective compilers.
Pick-to: 6.5 6.6
Change-Id: I0fd5847447bd8373e8e07f64dae11f27f48c915d
Reviewed-by: Alexandru Croitor (OOO) <alexandru.croitor@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
There is a chance that an unused variable warning will be treated as an
error, and in that case, this check will fail, and as a result FindEGL
will fail.
Pick-to: 6.2 6.5 6.6
Fixes: QTBUG-114431
Change-Id: Iaac49589144dbe4172ec58c6705a9f899c25f01f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We should sync external headers for 3rdpary projects
like freetype and harfbuzz-ng and keep the directory
structure.
Fixes: QTBUG-113416
Pick-to: 6.6 6.5
Change-Id: Ie66edb9a21cff37ca6c8c68b6d225de6d8bbad81
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
`TYPE` argument is not a thing, and if it is there, QT_BUILDING_QT is
set to `TRUE;CACHE;TYPE;STRING;When this is present and set to true, it
signals that we are building Qt from source.` instead of `TRUE`.
Pick-to: 6.2 6.5 6.6
Change-Id: I24784e9aead4929d408d06bce72d3f33ee21eb63
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
I think this needs to be more prominent, as I noticed during the testing
that it could cause issues if it gets lost in between the config
messages, as we knew of course.
Pick-to: 6.5 6.6
Task-number: QTBUG-113463
Change-Id: I2ece498a8d3604362a49cc10499b92b0d2764fb9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Android's toolchain file, ie., android-legacy.toolchain.cmake assumes
that the default build is a Debug build, and it adds the `-g` flag to
CMAKE_<LANG>_FLAGS, as a result, our release Android build always
contains debug symbols. In this patch, I basically move the `-g` flag
from CMAKE_<LANG>_FLAGS to CMAKE_<LANG>_FLAGS_DEBUG, and
CMAKE_<LANG>_FLAGS_RELWITHDEBINFO.
Pick-to: 6.5 6.6
Fixes: QTBUG-111901
Change-Id: I31eadb07d9172c923e8beaf0ac6c6e34fe1ebefb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Before this change, we had the following behaviors.
On platforms other than Windows-MSVC:
- when no build type was specified, we defaulted to Release
- when -developer-build was specified, we defaulted to Debug
- regardless of platform, unless the option was explicitly specified,
we never defaulted to -debug-and-release.
On Windows-MSVC, we always defaulted to Debug. Which is inconsistent
with the rules above.
The difference happens because CMake always sets CMAKE_BUILD_TYPE to
Debug during the first project() call when targeting the Windows-MSVC
platform.
We interpreted that as the user setting the build type, and thus we
didn't want to override what the user specified.
After this change, if we detect that it's cmake setting the build
type, we assign a build type that follows the non-Windows-MSVC rules.
This change unifies the behavior across all platforms.
Adjusted the configure help with the new reality.
Augments 33af62db37
[ChangeLog][configure] When no explicit build type is specified,
Windows will now default to building Release like the other
platforms.
Pick-to: 6.5 6.6
Change-Id: Id2bf269c51cf300ec09751ece2ad721869e0f90c
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This reverts commit 389507a047.
Reason for revert: The original patch unintentionally changes
the deprecation warning behavior for user projects. Merging
the current change will resurface the original static qt build
bug until a new fix is developed.
Pick-to: 6.6
Change-Id: I29b41b43fdd76b19bc46439470e04443dc2b8ddb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Yuhang Zhao <yuhangzhao@deepin.org>
