mkspecs/features/qt.prf adds a dependency on the system threading
library if the Qt Core thread feature is enabled. Because qt.prf is
loaded by any public or internal Qt project, it's essentially a public
dependency for any Qt consumer.
To mimic that in CMake, we check if the thread feature is enabled, and
and set the Threads::Threads library as a dependency of Qt6::Platform,
which is a public target used by all Qt modules and plugins and Qt
consumers.
We also need to create a Qt6Dependencies.cmake file so we
find_package(Threads) every time find_package(Qt6) is called.
For the .prl files to be usable, we have to filter out some
CMake implementation specific directory separator tokens
'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call
target_link_libraries() with a target created in a different scope
(I think).
As a result of this change, we shouldn't have to hardcode
Threads::Threads in other projects, because it's now a global public
dependency.
Task-number: QTBUG-85801
Task-number: QTBUG-85877
Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The include directory in Qt's build directory is always named
"include", no matter what the value of INSTALL_INCLUDEDIR is. The main
reason is that the name "include" is hard-coded in syncqt.
The INSTALL_INCLUDEDIR variable must only affect the installation
location of headers.
Fixes: QTBUG-85893
Change-Id: I5367bc589cba129eb41817e2b58d470f730bb5ac
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The logic is a bit involved in qmake.
The Qt internal qt_common.prf adds CONFIG += strict_c++ which applies
to qt modules, qt plugins, qml plugins, qt helper libs, winmain and
qt_apps, qt_tools, but NOT tests (which is important because the tests
on Windows MinGW fail to build without the GNU extensions).
Then default_post.prf checks for the strict_c++ value and either uses
the strict or non-strict C++ standard flags. default_post.prf is
loaded for all qmake projects, not just the Qt internal ones.
Now CMake doesn't provide a transitive based option to disable C++
GNU extensions with a mechanism similar to target_compile_features.
It only provides the CXX_EXTENSIONS property and it's associated
CMAKE_CXX_EXTENSIONS variable. We can't set the variable at a
directory scope, because that is too coarse grained.
So we rely on setting the property via a function in every relevant
qt_add_<target> function.
Now the naming of the function is weird.
We name the function as qt_internal_<...>, because it's not meant to be
used by Qt users.
We prepend an underscore to the name because we need to place it in
Qt6CoreMacros, so that the function can be called by
qt_add_qml_module which IS a public function.
That's because in Qt5 load(qml_plugin) was private API, but in Qt 6 +
CMake we decided to make qt_add_qml_module() as public API.
Change-Id: Id014626b087d590e25cb46843f93d0c67fc36e44
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Windows shared library prl files should not have a
QMAKE_PRL_LIBS section. Such information is not useful because it's
not used by the linker as per 523c7e3fd5
Amends 46d7abc9172f82756ccd3641a314dcc066353c3f
Task-number: QTBUG-85240
Task-number: QTBUG-85801
Change-Id: Ic40491a568f72c507a16322f6f0c61f98d3a5913
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Apply the same kind of transformations to the contents of the prl
files as we do for pri files. Mainly, transform system library paths
that are absolute, into link flags to make them relocatable across
systems.
Also change the Qt frameworks to be linked via the -framework flags
instead of via absolute paths.
Implementation notes
Move the common required functions for both QtFinishPrlFile and
QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file.
Make sure it's listed as a dependency for the custom commands.
Also make sure to pass the necessary input values like possible
library prefixes and suffixes, as well as the link flag.
Task-number: QTBUG-85240
Task-number: QTBUG-85801
Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This new function is meant to be used where load(qt_app) is used.
It delegates functionality to qt_add_executable, while handling
some additional behavior via a finalization function (mostly handling
of macOS Info.plist files and icons, as well as Windows icons and
resource files)
It uses a new PlatformAppInternal interface target.
Task-number: QTBUG-85757
Change-Id: I1a2d5851b137fcd4a6323e0e06fb154f91619800
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Our CMake build system only generated working .prl files for
the Release configuration in debug_and_release.
This caused a linking failure when building a Widgets example that
links against qtmain, specifically
qtmaind.lib(qtmain_win.cpp.obj) : error LNK2019: unresolved external
symbol __imp_CommandLineToArgvW referenced in function WinMain
The symbol is located in shell32.dll, which was not linked in, because
there was no qtmaind.prl file.
The fix to generate per config prl files is a bit complicated, because
add_custom_command does not support generator expressions in OUTPUT
and DEPENDS.
Instead we pre-generate 2 files per config, one with the preliminary
prl file content and another file that contains the final prl file
path (via generator expression).
Then we iterate over all configurations and create custom commands
with well known paths, and the final prl file is created by the script
called by the command.
Amends 06557312d2
Task-number: QTBUG-85240
Change-Id: I413b705bc69732b0cbe1ee8cd089a1aef19365db
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
On Windows, if Qt is built with Vulkan support but the user's machine
does not have Vulkan, it should still be possible to configure and
build an application (if the application does not use Vulkan of
course).
When Qt is built with qmake, the special windows_vulkan_sdk.prf file
makes sure not to export build time Vulkan include headers into the
generated .pri files. The same file also tries to find the include
headers via an environment variable. If it isn't set, it just adds a
bogus "/include" include path, which doesn't fail a user's application
build.
This wasn't the case for an application built with CMake, because the
exported Vulkan_nolink target uncodinitionally referenced Vulkan's
target properties. Which means that if the Vulkan package was not
found, the application failed to configure.
To mimic qmake's behavior, make sure to query the target properties
only if the Vulkan target exists, via the TARGET_EXISTS generator
expression.
Apply the same logic to all _nolink targets. This might not be
entirely correct in all cases, but we can revise this behavior later
after more feedback. At the very least it allows building non-Vulkan
based applications.
Task-number: QTBUG-85240
Change-Id: Iffbb03a84e8637ed54d0811433e66fe6de43d71f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Change added dep in qt_add_cmake_library():
PlarformModuleInternal -> PlatformCommonInternal.
Change-Id: I303a6a520f0dda7260b12cb21673b8f1a23d536b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It doesn't understand the arguments we usually pass to testlib.
Change-Id: Iea83d1d8c31a510b2bc442cbfc810eac631322e7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For repositories other than qtbase the QT_STAGING_PREFIX was empty,
because it was only determined in qtbase.
Also, we save the CMAKE_STAGING_PREFIX in the Qt6BuildInternals package
and set this variable if it's not explicitly set by the user.
As with CMAKE_INSTALL_PREFIX this behavior can be prevented by defining
QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX=ON.
Change-Id: I73100abbef24f5d3fb8f82029d0374176edc8048
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Fix the conditions in qt_add_simd_part for arch_haswell and the
avx512 profiles to mimic what simd.prf does.
Add missing SIMD flags in QtCompilerOptimization for arch_haswell.
Compute the compile flags for the avx512 profiles from the
profile dependencies.
Remove the special case in Gui that hardcoded the compilation of
qdrawhelper_avx2.cpp to be conditional on avx2 being enabled
instead of arch_haswell. The Gui project already has another
qt_add_simd_part that is enabled if arch_haswell is enabled, which
will now work correctly due to the fixes in qt_add_simd_part.
Change-Id: I7a61a03b5565d4fa438f22b329e0d9dd7acd9273
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qdevice.pri should embed info about the Android SDK, NDK, host,
platform api level and ABI.
The machine tuple test should not be run for uikit and Android
platforms.
Sysroot should also not be prepended for uikit and Android
platforms, otherwise it breaks Qt module include paths.
Task-number: QTBUG-85399
Task-number: QTBUG-82581
Change-Id: Ic48c88f6ab15d75c2ebc323c8d7a3b7e5596f3c1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add the cache variable QT_STAGING_PREFIX that is the same as
CMAKE_STAGING_PREFIX - if it's set, or CMAKE_INSTALL_PREFIX otherwise.
Use the variable in the places where we check for the emptiness of
CMAKE_STAGING_PREFIX to use CMAKE_INSTALL_PREFIX.
Change-Id: I372d57dfa41818c1965b824c59ab3cac80b38f60
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Interface libraries like our Qt header modules should not propagated
private defines which are meant only for building a specific Qt
module, and in the case of a header module there is nothing to build.
Exclude the usual private defines we set in qt_add_module for header
modules. This also fixes the content of header module .pri files.
Change-Id: I0791ebdb73e8b020ddb8116433ed36c7b3d71303
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
To achieve this, we save the result of the subarch test in the cache
variable TEST_subarch_result and use this value as the right hand side
of the QT_CPU_FEATURES.xxx assignment. The Qt6HostInfo package now
sets the variable QT6_HOST_INFO_SUBARCHS which will be used for the
host_build scope in qmodule.pri when cross-building.
Change-Id: I2c25f205bfc0692aef0d6f43ff4e542d27e1b948
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Apple deprecated the entire OpenGL API in favor of Metal, which
we are aware of, so we don't need to see the warnings when building
Qt.
Instead of applying the silencing globally for all Qt consumers,
both internal and external, we now limit the silencing to Qt itself.
That means user code that explicitly uses any of the deprecated APIs
will see the warnings. Note that this does not apply to merely using
any of the Qt OpenGL APIs. The user has to explicitly use the platform
APIs that have been deprecated.
The warnings need to be disabled on a build system level, so that
that they are passed as -D flags on the command line. If the defines
were done in Qt headers (qguiglobal.h e.g.), they would require the
user to always include this header before any of the Apple headers.
Change-Id: I3f2a2a5211332a059ad4416394251772c677fdcb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It wasn't possible to create a cross, non-prefix build with
CMAKE_INSTALL_PREFIX set to something else but the qtbase build dir
and CMAKE_STAGING_PREFIX set to the qtbase build dir.
This would be equivalent to
configure -prefix /usr \
-extprefix ~/my/qtbase/build/dir
Fix this by comparing the qtbase build dir against
CMAKE_STAGING_PREFIX if it is set. We also have to adjust the
QT_BUILD_DIR variable in a similar way.
Change-Id: Iaba5cf0f6954ae4b15d8af1fc62634f5d7f68835
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch modifies the two preprocessor definitions
QT_CONFIGURE_HOSTBINDIR_TO_HOSTPREFIX_PATH and
QT_CONFIGURE_HOSTBINDIR_TO_EXTPREFIX_PATH which are exclusively used
by qmake (and not QtCore's QLibraryInfo) to determine the ext prefix
and the host prefix.
In the qmake build of Qt, qmake considers the host prefix as "location
where qmake is installed". This is usually the same as the ext prefix
but can be modified by the user at configure time.
In the CMake build, we don't build tools for the host but always for
the target platform. The QT_HOST_PATH is an external prefix we never
install to. That means, the qmake we build is always installed into
the ext prefix (CMAKE_STAGING_PREFIX or CMAKE_INSTALL_PREFIX).
Therefore, we can calculate the path of <ext_prefix>/bin relative to
<ext_prefix> and use this value for both,
QT_CONFIGURE_HOSTBINDIR_TO_HOSTPREFIX_PATH and
QT_CONFIGURE_HOSTBINDIR_TO_EXTPREFIX_PATH.
The "path of <ext_prefix>/bin relative to <ext_prefix>" is equivalent to
just the "path <prefix>/bin relative to <prefix>", meaning we can
safely use <prefix>, which is just CMAKE_INSTALL_PREFIX.
Task-number: QTBUG-84886
Change-Id: Ie1d4628a7049ddfd0d0a56dfe4ee2f2bb4952277
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Building an iOS app with qmake failed because Qt itself was not built
with bitcode enabled.
Enable building with bitcode.
Make sure qrc resource files and bundled 3rd party libraries also
build with the regular Qt module flags and thus with bitcode enabled.
As a consequence gc_sections has to be disabled for UIKIT platforms.
Task-number: QTBUG-82581
Task-number: QTBUG-84781
Task-number: QTBUG-85240
Change-Id: I15fe668725a139c02f2a32a5db849b46d4ce325c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is required for qmake to correctly pick up and use plugins that
have strange characters in the types (slashes for platforms/darwin
type and dashes for wayland plugin types).
This fixes some issues with trying to build an iOS application
using qmake due to the qiosnsphotolibrarysupport plugin.
Task-number: QTBUG-85240
Task-number: QTBUG-84781
Task-number: QTBUG-82581
Change-Id: I94faf2d3dbbdeb22dbd96dfb11c7bff00645b524
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The EffectivePaths section does not inherit the Prefix value from
the Paths section.
Specfiy it explicitly, otherwise the paths reported by qmake -query
for /get variants ended up containing an extra "./bin/" part, which
ended up breaking building iOS apps with qmake.
Amends d7fd684861
Task-number: QTBUG-85240
Task-number: QTBUG-84781
Task-number: QTBUG-82581
Change-Id: I288a6e76a21d779a7e03443777f8a4ce28df9974
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Promotes qt_find_package()'d targets and their transitive dependency
targets to global scope. This will allow .prl file generation to
access targets in a sibling repo scope.
Retrofits qt_collect_libs() to be a bit more general, so it can be
reused both for prl lib collection, and traversing of dependencies
of qt_find_package() provided targets.
Removes the bail out checks for top-level static builds.
Amends 8c8c0f65e3
Amends dde11715d3
Task-number: QTBUG-84874
Fixes: QTBUG-84917
Change-Id: Id95b4cb7a0887c52f35c40bfdb96ad4a68dd6794
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Show a status message when we run syncqt for a module (gives a bit
more insight into why the configuration seems to stall for a moment).
Remove some uninformative messages about generating config.h files
and Depends headers, etc.
Change-Id: I5ff2774b9cf5d92ddde564dc09f4197c2835ee4a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qmake builds of Qt don't use libraries in /usr/local because the
path is not considered a system path. Only the SDK path should be
used as a source of system libraries.
We should do the same for the CMake builds, which involves a couple of
things.
Tell CMake not to consider /usr/local (and a bunch of other
paths) as system prefix paths.
Disable pkg-config usage which by default is not used in qmake
Windows and macOS builds.
If a user wishes to use libraries located in /usr/local on macOS, they
can explicitly enable the behavior via -DFEATURE_pkg_config=ON.
In addition to enabling pkg-config, that will also disable the system
prefix modification described above.
Implementation notes
To disable pkg-config usage, we set an empty path for
PKG_CONFIG_EXECUTABLE, because there is no other good way. The
downside to this is that a lot of warning messages will be printed
that the pkg-config package can not be found.
The pkg-config feature needs to be computed in QtBuildInternals before
qtbase/src/configure.cmake, because it's too late to do it in that
file where a few qt_find_package calls already exist.
The feature value is also saved to QtBuildInternalsExtra, to make sure
that pkg-config is disabled whenever building another repo.
System prefix adjustment is done by removing paths from
CMAKE_SYSTEM_PREFIX_PATH.
Ideally we would remove also /usr as a path, to match what qmake does,
but that breaks find_program() calls for perl, python, etc.
We have to make sure that qt_find_package does not look in
PATH when looking for packages, which is the default behavior, because
PATH on macOS most likely contains /usr/local.
One last curiosity for future generations is that CMake 3.18+ has
merged a change to prioritise SDK locations over regular /usr/lib.
Fixes: QTBUG-85261
Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This adds the CMake equivalent to the classical -device-option key=value
configure argument:
-DQT_QMAKE_DEVICE_OPTIONS=key1=value1[;keyN=valueN]
The keys and values get dumped verbatim into qdevice.pri.
This patch also ports the machineTuple configure test. Its result is
written into qdevice.pri as value for the GCC_MACHINE_DUMP variable.
Change-Id: I29f2323fd87639fafaed99ec7446c7ee75504705
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's now possible to pass -DQT_QMAKE_TARGET_MKSPEC=foo to cmake. If the
value is not passed, then we will guess the mkspec like we did before.
Change-Id: If6e8324654cb8bd83d3cba9eb6ee1e4ad2692a2c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For a cross-built, gcc-built Qt, the qmake build writes code into
qconfig.pri that adds the --sysroot flag to compiler and linker flags.
Follow suit in the CMake build.
To keep the diff small between the qmake-generated and CMake-generated
qconfig.pri files, the sysroot code is added at the top of
qconfig.pri, which is the reason for the new 'content' string variable.
Change-Id: I50649100e4368be64bf98ca19e46312e3ebf619d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When cross-compiling, we now create a target_qt.conf file that's to be
used with the host Qt's qmake. With "qmake -qtconf .../target_qt.conf"
projects can be cross-built against the cross-built Qt.
We also create wrapper scripts for the host qmake to save the user from
passing the -qtconf argument.
Fixes: QTBUG-82581
Change-Id: Ib5866e7e820369efea9eb3171e3e3e3ca5c0c3c1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before this change, the qt_lib_foo_private .pri files contained
absolute paths to libraries, e.g.
/usr/lib/x86_64-linux-gnu/libcups.so
Whereas the qmake build instead embeds link flags like -lcups.
Detect absolute library file paths, and transform them into link
flags. This should make the .pri files relocatable.
Fix the add_custom_commands to have the scripts as dependencies.
Make sure to pass the suffix, prefix and other options to the
qconfig.pri generation command as well.
Also reverse the order of the link flags, to mirror the order
that qmake generates for .pri files.
Task-number: QTBUG-84781
Task-number: QTBUG-85240
Change-Id: I7bc3b234d9c86c785b169b11f3042450aa225c1f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In a prefix build, this function uses install(PROGRAMS) which correctly
sets the executable bit. In a non-prefix build, we did file(COPY)
without explicitly setting executable permissions.
Now, we're also setting the executable bit for
qt_copy_or_install(PROGRAMS) calls in non-prefix builds.
Change-Id: I283e9aeed2a23016ee196d83d584a7eaaa5edd66
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
A developer could write 'ninja host_tools' to build the qtbase tools
and their dependencies, and then configure another cross-compiling
build dir pointing to the previous host build. This shortens the
workflow for cross-building when working in qtbase.
Change-Id: I69e70d23ce9df8669bcadf326d0586f097e5cb21
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Rather than embedding the full absolute path to the framework, we
should instead write a -framework Foo flag.
qmake seems to do this by specifying QMAKE_LIBS_FOO in the mkspec.
We'll try to get away with just deriving the name of the framework
from the path, to avoid having to introduce a mkspec equivalent
mapping for CMake.
This doesn't currently handle framework include paths, which qmake
also handled by harcoding QMAKE_INCDIR_FOO in the mkspec, and then
sysrootifying it via mkspecs/common/mac/sdk.prf.
Hopefully that's not really needed, given that -framework flag
should imply include paths as well.
Somewhat partially amends c254254c55
Task-number: QTBUG-85240
Task-number: QTBUG-84781
Change-Id: I70ea5021422d7b1f5afa9c4a595d1a9b8a8217d3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Otherwise the Objective-C++ sources will be built with the default
compiler visibility (visible), and then linked with moc-generated
C++ sources that have the Qt overridden hidden visibility, resulting
in linker warnings such as:
ld: warning: direct access in function 'X' from file 'moc_foo.cpp.o'
to global weak symbol 'Y' from file 'bar.mm.o' means the weak symbol
cannot be overridden at runtime. This was likely caused by different
translation units being compiled with different visibility setting
Change-Id: I22e15e7e181a74de8c0a22c73d06e600e582d7fd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is required for qttools, where the configure.cmake file lives in
the top-level source dir, but the module is in src/global.
The new CONFIGURE_FILE_PATH option allows specifying a different
location for the configure.cmake instead of the default value.
Change-Id: I260d7c93dd49337ebe07ae4cc871394da9e9c2c6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The qml app was crashing when used by qtdeclarative auto tests. It
complained about unregistered QML types. qmltyperegistrar didn't
create registration info for these types. moc didn't output class info
about these types because the build system didn't provide the proper
include paths.
In qmake land, moc was given 2 sets of paths when building a module:
the non-installed framework dirs as -F flags, and also the
$repo_build_dir/include paths as regular -I flags.
In CMake land we only gave include paths to the non-installed
framework dirs as -I flags, not -F flags.
That's because AUTOMOC checks for a specific pattern in the include
paths to transform them into framework include paths
(existence of Foo.Framework/Headers symlink),
and we didn't pass such an include path.
Make sure to mimic what qmake does, and pass -I flags to
$repo_build_dir/include as public include paths, but only via
BUILD_INTERFACE aka when building Qt itself.
Also pass -F flags by specifying framework include paths in the
pattern that AUTOMOC expects.
Fixes the following qtdeclarative tests
tst_qdebugmessageservice
tst_qqmlinspector
tst_qqmlenginedebuginspectorintegration
tst_qqmlpreview
Task-number: QTBUG-84886
Change-Id: Iab9693d9889bf6d2c40fed067ab9b9da8683a053
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We must filter out expressions of the form $<TARGET_PROPERTY:name>, because
1. They cannot be used in file(GENERATE) content.
2. They refer to the consuming target we have no access to here.
The CMake error
Error evaluating generator expression:
$<TARGET_PROPERTY:QT_PLUGIN_CLASS_NAME>
was triggered when building the UiPlugin module of qttools.
Change-Id: Idf639be50120b94d68a70965604e6f1ef72edc9b
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Assuage the fears in the previous commit, by actually querying and
using the public defines set on a target, rather than hardcoding one
single QT_FOO_LIB define + the extra namespace define.
This should future-proof .pri file generation for qmake mixing.
Amends 3452b08df6
Task-number: QTBUG-84781
Task-number: QTBUG-84881
Change-Id: Ide68ecf3f89be6d5462cfe43706c27f9cb53394f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
While we recorded the namespace define in the CMake generated Targets
file, we also have to record it in qt_lib_core.pri, so that qmake
knows to use the define when building other modules / apps.
It does scare me what other MODULE_DEFINES we might be missing, and
that we should perhaps put all public modules defines into the
generated module .pri files.
Amends 3452b08df6
Task-number: QTBUG-84781
Task-number: QTBUG-84881
Change-Id: I3175aa9991a06a4541eb0dd153ba2e6e58c019ce
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Previously .prl files were created via add_custom_command with a
POST_BUILD command. This means they were only created after linking
the libraries, and that whenever a relinking happened, dependees had
to rebuild many parts of their target.
Ideally we would use generator expressions in the OUTPUT argument, but
versions up-to CMake 3.18 don't support doing that.
A workaround is to create and depend on a .prl file name without
generator expressions, and as a side effect also create a .prl file
that does use generator expressions, but don't specify it as an
OUTPUT.
This seems to work well, and improves the dependency tracking issue,
at the cost of one more file copy per .prl file whenever it changes.
Change-Id: I7dd99777fec5a08552503bdbafb6116f93ebe66b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Use ARGN that already has the out_var parameter removed.
Change-Id: I79438caa4333a11493456fa219448ad500518880
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The referenced Qt libraries had paths to the build directory, instead
of the $$[QT_INSTALL_LIBS]/ prefix. The reason was two-fold:
1. QT_BUILD_LIBDIR had the wrong value, namely
"${QT_BUILD_DIR}/platforms/qfoo".
2. The QtFinishPrlFile.cmake script was called with a wrong OUT_FILE
parameter, placing the final .prl file in the build lib dir.
As drive-by change, surround arguments for QtFinishPrlFile.cmake that
can contain spaces with double quotes.
This amends 8c8c0f65e3.
Task-number: QTBUG-84781
Change-Id: I7188b799716576b3296ee7b2d460489867b9967a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Document what qmake expects and what CMake creates by default.
This change should fix qmake mixing for MinGW, where the WinMain
library was called qtmain.a instead of libqtmain.a.
Amends f626c73b28
and 9b0e23ef8a
Task-number: QTBUG-84781
Change-Id: I059db13f8d8a0aab8bd3fc69d4537a2b63687394
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To make sure qmake generates appropriate rules when building other
applications.
Task-number: QTBUG-84781
Change-Id: I75618575602be820bf20a8067e3a6ee3ff7e7950
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qtremoteobjects has a tool that uses qt_process_qlalr. The function
doesn't have a check to see if the consuming target is an imported
target, to skip doing any work when corss compiling.
Fix it, like we do in qt_extend_target.
Change-Id: Ide389a371aa07225f08689d15125c04d8b0e3916
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Since commit e343affd63 we're creating object libraries for Qt
resources in static libraries. Those must be reflected in the
generated .prl files for static builds of Qt.
In qt_add_resource, we now calculate the install locations of the
object files of rcc-generated C++ files and save them in the target
property QT_RCC_OBJECTS. This property is then passed to
QtFinishPrlFile to write the object file paths to the .prl file.
Change-Id: Ic383892d723d02fc91f712bc2dbcbc90babad074
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
A lot of qtdeclarative tests fail due to not finding the
QtTest qml plugin in ${prefix}/qml. This is just the symptom, the
problem is that the combination of CMake + MinGW + Qt relocatability
behaves incorrectly.
The value returned by
QLibraryInfo::location(QLibraryInfo::Qml2ImportsPath) for the
qmltestrunner executable is ${prefix}/bin/qml which is incorrect.
This happens due to a combination of things. The
c33916a279 change in qtbase introduced
checks to figure out whether an application is a windeployqt-ed app
to adjust the prefix path.
This check tries to find the import library libQt6Core.a in the lib
subfolder whenever the executed app dir path is equal to the
computed prefix path.
If it's found, the code assumes we are running a tool in
${prefix}/bin. If it's not found, the code assumes it's a
windeployqt'ed app, where the Qt .dlls are next to the executable.
Currently when QtCore is built with CMake targeting MinGW, we actually
create a libQt6Core.dll file instead of a Qt6Core.dll file, and also
an import library called libQt6Core.dll.a, instead of libQt6Core.a.
The prefix check code actually prepends an additional "lib", thus
trying to find the liblibQt6Core.a import library.
This fails, the code assumes a windeployqt'ed app, and returns the
currently executed app path dir as the prefix aka ${prefix}/bin in
the case of qmltestrunner, and thus none of the qml plugins are found.
To fix this, generated the shared library and the import library names
as qmake expects them, aka Qt6Core.dll and libQt6Core.a.
Some of this renaming was done for MinGW plugins and shared libraries,
but not for modules in 9b0e23ef8a.
Extract the duplicate code and apply it to all shared libraries built
by Qt on Windows. Adjust the prefix and suffix accordingly, depending
on whether we use MinGW or not.
Amends 9b0e23ef8a
Task-number: QTBUG-84886
Change-Id: I5a8618597df5f57ce256739adced3f24eb13dac7
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The change fixes the labels to show up correctly in the configure
summary.
It also allows enabling the sanitizer via the feature flags, e.g.
-DFEATURE_sanitize_address=ON.
Finally the qtbase sanitizer option is saved in QtBuildInternalsExtra
so that repos built after qtbase have the same sanitizer options
enabled.
Change-Id: Ic9d9e3ce3c7ebbc244ced2e6d163d1ac8ee06b12
Fixes: QTBUG-84721
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To successfully link plugins of a static Qt build into a Qt project we
need to generate .prl files for the plugins.
Task-number: QTBUG-84781
Change-Id: I1406052f2269050aa7cbe6aa2b546bece1c68467
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In qmake land the define is set in mkspecs/common/macx.conf which
means it should be public for all Qt consumer apps as well, not just
internal targets. Make it so.
Amends 17be43c58e
Task-number: QTBUG-83929
Change-Id: I9f9d7dfca24b54977cb8364723c3618d3fec2e73
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The qt_internal_apply_gc_binaries function should apply both compile
and link flags, not just link flags.
The flags should be applied publically to all consumers of Bootstrap
regardless if the gc_binaries feature is enabled.
The flags should be applied publically to Core only in case if the
feature is enabled (aka for static builds only).
Change-Id: Id42af0d9b527004d74c04eff2c9e3c2be1e76aac
Fixes: QTBUG-84461
Task-number: QTBUG-83929
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This mirrors what qt_tool.prf does.
Task-number: QTBUG-83929
Change-Id: I892a3f5f62d461456abfa414718fcc4c4c05c012
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Like in the qmake build, we now set the target description of a Qt tool
to a value, different from the description of the Qt libraries.
Fixes: QTBUG-84900
Change-Id: I93419ddd513c83fe8488e70b5a8328cadc3541c7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a qmake build this file serves the purpose of setting the right
prefixes for the build directory's qmake binary. This can be used to
build Qt repositories other than qtbase, esp. in a top-level build.
In the CMake build, we don't have qmake top-level builds, and we do not
support building Qt repositories with the build directory's qmake binary
(exception: non-prefix build).
To build a Qt module or user project with qmake, the installed qmake
must be used.
This fixes qmake for non-prefix top-level CMake builds.
Change-Id: Ibd10c36e8359225553d782d0c8117760db9f3370
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In static builds, due to our CMake design for auto-linking plugins
being incorrect we sometimes cause link failures on Linux in leaf
modules, because the link line order is incorrect.
So far such failures were fixed by explicitly modifying the order of
libraries on the link line in each failing CMake project.
This proves to be problematic because the failures appear in seemingly
random integrations that don't even touch the build system parts.
Until we fix the design, another less performant but more
general / safe way is to increase the link interface multiplicity,
which causes a cycle of libraries to be repeated more than 2 times
on the link line, thus giving the ld linker more chances to figure out
which symbols are needed for linking.
Implement this for Linux static builds to avoid random integration
failures for people that know nothing about this issue.
The link multiplicity for all qt modules is increased to 3, thus
QtGui would be repeated 3 times on the link line of each dependent
library. The value is also configurable via the
QT_LINK_CYCLE_MULTIPLICITY cache variable.
Task-number: QTBUG-83498
Change-Id: I2fd2bb2b5e7fec4e3ef5d1194668b524d20f7067
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It used to be called HAVE_DASH_UNDEFINED_ERROR, but that always
cause Coin to print the compile check as the first build error snippet
because it contains the word "error", and whenever you get emails from
Gerrit the first snippet is always this compile check.
Rename it to avoid confusion in emails and Coin status reports.
Change-Id: I5487623abf9df177b100d2b45635688504f0e25a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
For static builds of Qt we installed the plugins into the lib
directory. However, they are expected in the plugins directory tree.
This happens, because we pass a value of an uninitialized variable to
ARCHIVE DESTINATION in the qt_install call in qt_internal_add_plugin,
and CMake defaults to "lib".
This flaw was introduced in b42feb02ce with the following intent:
"This patch also changes add_qt_plugin() to use the value provided in
INSTALL_DIRECTORY for ARCHIVE_INSTALL_DIRECTORY if no value is provided
for the latter."
The patch changed the value of arg_ARCHIVE_INSTALL_DIRECTORY but
missed to set the variable archive_install_directory, which is
actually used in the qt_install call.
We now directly set archive_install_directory and remove the unused
archive_install_directory_default variable.
Task-number: QTBUG-84781
Change-Id: Ifd0475d8452272e8765bf42fd912a45cfa3dbbd1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Because find_package usually creates targets in a local scope,
qt_generate_prl_file fails to generate a .prl file that has
references to generator expressions like
"$<TARGET_FILE:Freetype::Freetype>" which references targets
that are not found in that specific scope (e.g Freetype target is
present in qtbase scope, but not qtsvg scope).
This happens in static top-level Qt builds, and thus fails the
configuration. While we try to figure out how to fix this adequatly,
don't generate .prl files in such a configuration.
Task-number: QTBUG-84874
Change-Id: I69cf0ad1419d21e3676e1374624601f00936c405
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qmake_use.prf understands the _DEBUG and _RELEASE suffixes for
QMAKE_LIBS_XXX entries. The CMake configuration "Debug" is considered
for the _DEBUG entries, "Release" and "RelWithDebInfo" for _RELEASE.
The qt_lib_XXX_private.pri files are now generated in multiple steps:
1. The QT_LIBS_XXX information is generated per $<CONFIG> and written to
.cmake files.
2. A preliminary qt_lib_XXX_private.pri file is generated, containing
only configuration-independent data.
3. A custom command runs the QtGenerateLibPri.cmake script that combines
the files from step 1 and 2 into the final qt_lib_XXX_private.pri
file.
The same is done for mkspecs/qmodule.pri.
To be able to trigger custom commands from header modules, which are
interface libraries, we introduce one XXX_timestamp ALL target per
header module that creates a timestamp file. To that XXX_timestamp
target we add the pri file generation target as dependency.
Fixes: QTBUG-84348
Change-Id: I610f279e37feeb7eceb9ef20b3ddfecff8cfbf81
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The module pri files of internal modules did not expose any include
paths. They must have both, the public and the private include paths.
Task-number: QTBUG-84781
Change-Id: I3cbe94d4e49c754e49d26b00012e668b0afbdc8f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
MinGW plugins should not have the lib prefix in the shared library
names. Do this manually for a couple of libraries, and also for the
generic qt_add_cmake_library function.
Amends 9b0e23ef8a
Change-Id: I1cfaf8fc046f86edd3e755adfa599aa0aa854ee3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Include headers in .pri files should point to the framework Headers
dirs.
The module name in the .pri file is not versioned when it's a bundle.
Paths to system frameworks in .prl files should instead be replaced
with -framework Foo flags.
Change-Id: Ia353d033799fae40a1bc55fad6f86b2c8ef76c56
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Qml tests currently don't expose a CMake target, so no
dependency should be added to a non-existent target.
Make sure to add the check target only if the test was previously
added.
Fixes configurtion failure of qtdeclarative tests.
Amends 873aa682c5
Change-Id: Ic8bbfe668c00c1ce05f1e1dfe5494dafd91dd7b8
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This patch allows tools to be built for the target platform when the
QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration
time.
To avoid naming conflicts, the target tools are suffixed with "_native".
The qt_get_tool_target_name() function can be used to get the tool name
for both scenarios (cross and non-cross compilation).
Extend pro2cmake to refer to the right target name for tools.
The relevant write_XXX functions have a new target_ref parameter that
will be "${target_name}" for tools and literally the target name for
everything else.
Fixes: QTBUG-81901
Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Given a test named "tst_qdrag", you can run "ninja tst_qdrag_check"
to build and run the test.
Change-Id: I47dccb39dd60fca9cb07ff9af9fb739b293c5aaf
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This avoids issues with some special characters and spaces.
Change-Id: I6b7cedbe2c9663f62fae104488454faebab52ce0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake sets "lib" as default prefix for Windows-GNU platforms.
Change-Id: I49e3123c385610307c84c584a21f5f3827a6fafd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The function name has been changed upstream (3.18).
Change-Id: I76a26cdc8de71dffa5402a7c7423006a7a01552e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's only calls were with the PUBLIC argument, so remove the argument
both in the declaration and call sites, and just return the public
dependencies.
Fix up the names of the variables as well.
Amends b56dc55c3a
Change-Id: I830c1894376d0d3a2eb2bd4ffa38a1b3b3066292
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Previously we checked the LINK_LIBRARIES property of the main module
target, but we should instead use the values of
INTERFACE_LINK_LIBRARIES set on the FooPrivate module.
Because both versionless targets and private targets are interface
libraries, we need to properly differentiate between them when
following versionless targets to their main associated target.
To do that, instead of using string comparison, export an additional
private _qt_is_versionless_target property, and query that.
Also make sure to set and export the _qt_config_module_name property
on the FooPrivate targets.
Also make sure to APPEND to EXPORT_PROPERTIES rather than override
(looking at you QtFeature.cmake).
Task-number: QTBUG-75666
Change-Id: Ia3261e218840e9f5217ab49755e8c876560e294d
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Qt module targets now export the "_qt_config_module_name" property,
which contains the module's name in qmake land. This can be different
from the lower case target name (e.g. Test vs testlib). This exported
property is used when retrieving the dependencies of a module outside
of qtbase.
The property's name is a bit odd and lower case, because we want to be
able to set it on INTERFACE_LIBRARY targets, for instance header
modules. This CMake pecularity is described in
https://gitlab.kitware.com/cmake/cmake/issues/19261
Fixes: QTBUG-84287
Change-Id: I4a75af3ebeabebc56a0f77d464e45ab7fd81eafa
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit e875f45805.
Reason for revert: syncqt creates a master header that includes
the *Depends header. Therefore we must always create the *Depends
header. Ignore for now that *Depends headers are empty and pointless
for module headers.
Change-Id: I1dcc836788b3d46c4f1b504d2d64e9eb67b66206
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For now, we have to turn off the 3rdparty lib generation code for
qt_lib_XXX.pri files, because it's broken for NMC if the 3rdparty
libraries have different binaries per config.
The actual fix is more involved.
Task-number: QTBUG-84348
Change-Id: I863e69085b68c0dbbb3f6c415111bc255799e155
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Introduce a qt_finalize_module function that is called as a
CMakeLists.txt finalizer and call qt_generate_module_pri from there.
This is done in preparation for writing the QT.XXX.depends entries to
the module pri files, because we must do this after all dependencies
have been added.
Change-Id: Ia61db73383541651389fd647523ef535792874d4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If an OUTPUT_DIRECTORY option is provided, it should be used instead
of discarding it.
Change-Id: Ie53b56616f16589f7c05ff9378d7ba2e2ba34726
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The module pri files are supposed to add their public features to the
global QT_CONFIG variable.
Change-Id: I9a1719f897747a1d89011b1f1231c05a23539def
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Avoid writing module_plugin_types-NOTFOUND into the module .pri files.
Change-Id: I2fed7b0d1c21e2233eebcaca419f522a07d22af4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For modules that are not yet ported to CMake and that use
QMAKE_USE += libfoo
we need to provide the information about libfoo in the qt_lib_XXX.pri
files.
Also, we now generate qt_ext_XXX.pri files for bundled 3rdparty libs.
Task-number: QTBUG-75666
Change-Id: I9e4b057a197554ecb37c294c0bf09e2a2b3aa053
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When using Ninja Multi-Config, we don't want to install a "Release"
moc.exe, and then override it with a "Debug" moc.exe.
Because it doesn't seem possible to exclude installation of targets
per configuration, put the non-main configuration tools into
configuration specific subfolders like "bin/Debug", so no overriding
happens upon installation.
Introduce a new function qt_get_install_target_default_args() which
returns install destination arguments for consumption in qt_install()
calls. The function adds the config-specific suffix to the destination
for the appropriate configs.
Each call to qt_install *adds* new rules for installation,
which means that export registration needs to happen only on the first
call.
Make sure qt_add_tool doesn't ask qt_add_executable to install
yet again, to create duplicate rules.
Apply the same install arguments logic to qt_add_executable calls.
Task-number: QTBUG-80900
Task-number: QTBUG-80901
Change-Id: I3e732d27dba5bf5f8059d2878ef1e425237d383a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Set the target property INTERFACE_MODULE_IS_HEADER_ONLY for
header-only modules, and only create *Depends header files if this
property is falsy.
Change-Id: Ic6b100787d18b3ff1f7b9d0f2b5c744018b1f295
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This value is the equivalent of qt_module.prf's MODULE_INCNAME and can
be used to specify a name for the module's include subdirectory. The
default is Qt<ModuleName>.
The include name is stored in the module's target property
MODULE_INCLUDE_NAME.
Change-Id: Ie6c8f6882ee2c3db78884ae5781593c803be3c05
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And enable the same default when building Qt itself (it's implicit).
Allow opting out on a target-by-target basis, by using the public
qt_disable_utf8_sources() API call.
Change-Id: Ifc19a744d57b96b1c74a6926a0c6628c2a820464
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Before, we were setting those properties only for Qt modules.
Now, Qt executables and plugins have a full VERSIONINFORMATION
resource on Windows.
Also, extend the CMake API with the possibility to pass target
information to modules, plugins and tools. This will be used in a
subsequent commit.
Change-Id: I2bb8d3637569e0eaec76f56331bc23282285d872
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way.
The following story inspired this change.
If a user wants to build a Qt repo into a different install prefix
than the usual Qt one, this will fail configuration because we
look for various things like syncqt, qdoc, etc relative to
CMAKE_INSTALL_PREFIX, which will now point to a different location
where none of the above tools are located.
The intent for such a use case is to support building Qt packages with
Conan, which sets a random install prefix when configuring a repo.
The idea is to derive the qt prefix dynamically from the
QtBuildInternals package location. Essentially it's a reverse relative
path from the QtBuildInternalsConfig.cmake file to the install prefix
that was specified when initially configuring qtbase.
Once the dynamic prefix is computed (so we know where the possibly
relocated Qt is), we can find tools like syncqt and qdoc.
This is an initial attempt to support a use case like that.
More design work will probably needed in case if tools / libs need to
be found in a location different than the Qt install prefix (so
support for multiple install prefixes / search paths).
An example of such a case would be when building qtdeclarative and
qtquickcontrols2 as Conan packages in one go. Most likely the
qmltyperegistrar tool will be located in the random install prefix
set by Conan, so building qtquickcontrols2 might fail due to not
finding the tool in the original Qt install prefix.
As to the implementation details, the change does the following:
- Dynamically computes and sets the
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when
find_package()'ing QtBuildInternals. It's an absolute path
pointing to where the relocated Qt is.
- When building qtbase this variable is not yet available (due
to QtBuildInternalsExtra not existing), in that case we set
the variable to the absolute path of CMAKE_INSTALL_PREFIX
(but only for the initial qtbase configuration).
- Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used
for standalone tests purposes. It's not needed now that we compute
the location of the Qt prefix dynamically.
- The Unixy qt-cmake and qt-cmake-private shell scripts now
use a relative path to find the toolchain file we created.
- The toolchain file also dynamically computes the location of the Qt
packages, and adds them to CMAKE_PREFIX_PATH.
- A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding
tool locations, mkspecs dir, path environment setup for tools, etc.
- Some places still use CMAKE_PREFIX_PATH in the following cases
- When determining paths while configuring qtbase (valid cases)
- When I wasn't sure what the behavior should be, so I left them
as-is (an example is documentation generation, do we want to
install it into the random Conan prefix, or into the main prefix?
Currently it installs in the random prefix).
Note that relocating a Qt installation does not work for non-prefix /
non-installed builds, due to hardcoded paths to include directories
and libraries in generated FooTargets.cmake files.
Task-number: QTBUG-83999
Change-Id: I87d6558729db93121b1715771034b03ce3295923
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This is needed for building Qt plugins with qmake against other
CMake-built modules.
Change-Id: Ibd6ad0b08645c798be74285b24f71add947bea88
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Due to the install prefix being changed for standalone tests,
the correct $qt_prefix/bin folder was not added to the PATH
environment variable when running tests.
Make sure to always include the the original qt install prefix,
even if a different install prefix is specified when configuring
standalone tests.
Amends 39090ea15c
Change-Id: I22aab732bb2bb679074a811d28d8209e1d535df3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... and update handling of CLASS_NAME in qt_internal_add_plugin
Change-Id: Iec8e5f9f80df02c9ba21648535872988839f4b64
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
