summaryrefslogtreecommitdiffstats
path: root/cmake/QtBuild.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: build add flags for building QtAndroid.jarAssam Boudjelthia2020-09-161-0/+1
| | | | | | | | | | | | | Adds -source, -target, -Xlint:unchecked, -bootclasspath flags. Setting default javac build source and target versions to 8. Allow setting custom values for javac build versions via -DQT_ANDROID_JAVAC_SOURCE, and -DQT_ANDROID_JAVAC_TARGET. Task-number: QTBUG-86282 Change-Id: I98f4f193ac96016dc722d178594d7fd401202f68 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix rpaths set for Qt internal apps like DesignerAlexandru Croitor2020-09-111-0/+9
| | | | | | | | | | | | | | | | | qt_apply_rpaths takes into account properties like MACOSX_BUNDLE. This property might not yet be set when qt_internal_add_app is called, but later. To handle that, move the call of qt_apply_rpaths to qt_internal_finalize_app. As a result, the installed apps will have 2 rpaths, the $ORIGIN style relocatable one, and an absolute path one pointing to the Qt prefix/lib. The last one might be unnecessary. Fixes: QTBUG-86514 Change-Id: I25e0d695c78c8b5703e94c99cc2457f772721456 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Port headersclean check to CMakeKai Koehne2020-08-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Configure Qt with -DQT_FEATURE_headersclean=ON to enable the check. There will be separate target for each module include (e.g. QtCore_header_check), but the check will also be done when the module is built for the first time. There are notable differences to the qmake version: - the build does not pick up anymore default defines or flags from the module, or Qt. Instead options like -fPIC they have to be listed explicitly. Also for this reason, we have to skip the vulkan-related headers from the check, since vulkan/vulkan.h is not necessarily in the compiler's default search path. - some checks for nowadays unsupported compiler versions are removed. - -Wdouble-promotion -Wshorten-64-to-32 is not added for clang builds; the qmake code path did never enforce that on CI machines (it was non-Apple clang only), and the check currently fails on these configurations. Fixes: QTBUG-82615 Change-Id: I1cd303677b1472116910b6c27748f96436feb35e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake Build: Add QNX 7.1 build supportCristian Adam2020-08-201-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | This commit allows building Qt6's QtBase using QNX 7.1 and a toolchain file which is almost identical to what CMake has in its documentation: https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling-for-qnx set(CMAKE_SYSTEM_NAME QNX) set(arch gcc_ntoarmv7le) set(CMAKE_C_COMPILER qcc) set(CMAKE_C_COMPILER_TARGET ${arch}) set(CMAKE_CXX_COMPILER q++) set(CMAKE_CXX_COMPILER_TARGET ${arch}) set(CMAKE_SYSROOT $ENV{QNX_TARGET}) The only difference is the usage of q++ instead of QCC, which is no longer present in QNX 7.1 SDK. Task-number: QTBUG-83202 Change-Id: I51031540721275f2ee83cee9e7df4994a65db0e2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Implement configure -qreal <type>Joerg Bornemann2020-08-191-0/+4
| | | | | | | | | The configure argument -qreal <type> maps to the CMake argument -DQT_COORD_TYPE=<type>. Fixes: QTBUG-83325 Change-Id: I94970f31ccfb241b1dd4f1d9b6cef25d6684dc05 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Split QtBuild.cmake into smaller filesAlexandru Croitor2020-08-141-5805/+36
| | | | | | | | | | | | | | | | | | | | | | | QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow opting out of global target promotionAlexandru Croitor2020-08-131-2/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The endless saga of fighting with qt_find_package and global target promotion. In certain scenarios we want to opt out of target promotion to global scope. One such case is in qttools with WrapLibClang and Threads::Threads. Threads::Threads will be found in the top-level scope via Qt6Dependencies. WrapLibClang is declared in src/ directory scope, and then we try to promote it ands its dependencies to the global scope, via qt_find_package() -> qt_find_package_promote_targets_to_global_scope(). This fails because we can't promote Threads::Threads due to it being added in a different subdirectory scope. Introduce 2 new functions. qt_internal_should_not_promote_package_target_to_global and qt_internal_disable_find_package_global_promotion. The first one is used to disable promotion of targets to global scope in qt_find_package. To mark a target not to be promoted, the second function is used. It will be used by qttools for the WrapLibClang case. Task-number: QTBUG-85877 Change-Id: If6caf10a94999402026517a623ae29e3ab1eeb7f Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow specifying a sysconfdir that's outside the prefixAlexandru Croitor2020-08-131-10/+17
| | | | | | | | | Also use the value to actually write it into qconfig.cpp so that qmake reports the right information. Change-Id: Icc4bf36b0dc6ad75d93ac16f39e5b361c0ce52b4 Fixes: QTBUG-81289 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix empty value of CMAKE_SIZEOF_VOID_P when looking for toolsAlexandru Croitor2020-08-131-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our initial approach to looking for host Qt tools when cross-compiling to a platform with a different architecture bitness compared to the host one was to unset CMAKE_SIZEOF_VOID_P before calling find_package(Qt6FooTools) and then restoring the value. That works to bypass the architecture bitness test in the ConfigVersion files, but it also influences the paths that find_package() searches in, specifically the lib<arch> paths like /usr/lib64 will not be searched in. Fortunately since CMake 3.14, write_basic_package_version_file() can take an additional ARCH_INDEPENDENT parameter. This disables the architecture bitness test when looking for the package, while allowing to still search in the /usr/lib64 like paths. Use it when creating the QtFooToolConfigVersion.cmake files. One could argue we should actually check if the tool executables could run on the host system where find_package is called for cross-compilation. We could do that in another change if the problem ever arises. Amends 03aa74e40d8f1270e1bb28d0791e5bc376ffa0b7 Amends 914b367c7f6a117130b8a56338c46a8102a1f77f Change-Id: I1181ff637ac80064a6a8538170b28a41743fc90c Fixes: QTBUG-81672 Reviewed-by: Christophe Giboudeaux <christophe@krop.fr> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Write QMAKE_MACOSX_DEPLOYMENT_TARGET to qconfig.priJoerg Bornemann2020-08-131-0/+2
| | | | | | | | | | | | | If the user specified CMAKE_OSX_DEPLOYMENT_TARGET=10.15 for the Qt build then building projects with qmake failed, because the mkspec hard-codes QMAKE_MACOSX_DEPLOYMENT_TARGET to 10.14. We now write QMAKE_MACOSX_DEPLOYMENT_TARGET to qconfig.pri to override the mkspecs' default. Fixes: QTBUG-85923 Change-Id: I6a39cfe047ac0f99e1da0ca0728d63c741bd4fed Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add missing newline at the end of qconfig.priJoerg Bornemann2020-08-131-1/+1
| | | | | Change-Id: I929d74234b685bf0684d3067f7f958d474df20ff Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix Threads::Threads dependency handling with CMake < 3.18Alexandru Croitor2020-08-121-0/+20
| | | | | | | | | | | | | | | | | | | | Apparently CMake encods targets from different scopes with a different encoding scheme for earlier CMake versions. CMake 3.16.3: Threads::Threads::@<0x5604cb3f6b50> CMake 3.18.0: ::@(0x5604cb3f6b50);Threads::Threads;::@ Handle the earlier version approach as well. It needs to be done both when writing out 3rd party dependencies, as well as for lib prl files. Possibly in more places as well, but I didn't detect additional places yet. Amends 92ee9bd6b885879090ba57e49c8bd84a06d42b2b Task-number: QTBUG-85801 Task-number: QTBUG-85877 Change-Id: Ib348b51b2d623fb50d9080dba2beeb931d47a69c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Prepare ground work for static Qml plugins importingAlexandru Croitor2020-08-121-7/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | For qt_import_qml_plugins to work, it needs to have access to the Qml plugin targets by the time find_package(Qt6Qml) is called. To do that, we modify the generation of Qml plugin Config, Targets and Dependencies files to go into a special 'QmlPlugins' subfolder of the Qml package. The Qml package will then GLOB include all the Config files in that folder, to make them available whenever find_package(Qt6Qml) is called. This is similar to how the Qt plugins were glob included in the CMake integration of Qt 5.15. In fact that glob including is missing in Qt 6 for regular Qt plugins, and should be implemented in a following change. Currently the Qt Plugins config files that are included are hardcoded to the list of known plugins at Qt configuration time. As a drive-by to make this all work, the naming of the various Config and Dependencies files has been normalized to include the Qt6 prefix. This is done for both regular Qt plugins and Qml plugins. Task-number: QTBUG-85961 Change-Id: Id20da72337ca2945fa330ea6fb43535e44a83292 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix prl files of static Qt buildsAlexandru Croitor2020-08-061-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Static Qt plugins should not be included in the list of libraries of a prl file. They end up being there due to our circular dependency trick where the plugins depend on the module they belong to. This in turn causes the giant static plugin generator expressions to be processed in qt_collect_libs(), and the generated prl file ends up having target names like Qt6::QJpegPlugin which are obviously not linker flags. To eliminate the static plugins from prl files, add an additional dummy boolean generator expression '$<BOOL:QT_IS_PLUGIN_GENEX>' that always evaluates to true. We can string match on this expression in qt_collect_libs, and thus remove the whole static plugin genex entry. This should fix linking of apps with qmake that use a CMake-built static Qt. Task-number: QTBUG-85865 Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I949dc5edb10d94c4ab84ed430af7c164d8efaaa6 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Properly handle CONFIG += thread aka Threads::ThreadsAlexandru Croitor2020-08-061-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Fix build with custom INSTALL_INCLUDEDIRJoerg Bornemann2020-08-061-8/+7
| | | | | | | | | | | | | 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>
* CMake: Don't build debug tools by default in debug_and_release buildsJoerg Bornemann2020-08-051-0/+5
| | | | | | Fixes: QTBUG-85411 Change-Id: Idd9664d1a9143c31f28549a72823a82df1cff7ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't use std=gnu++11 when building Qt internal targetsAlexandru Croitor2020-08-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Don't generate prl libs for Windows shared libsAlexandru Croitor2020-08-041-7/+15
| | | | | | | | | | | | | 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 523c7e3fd55c853dd424d57f28e225d57439cf89 Amends 46d7abc9172f82756ccd3641a314dcc066353c3f Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: Ic40491a568f72c507a16322f6f0c61f98d3a5913 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix generated content of prl files (again)Alexandru Croitor2020-07-311-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Introduce qt_internal_add_appAlexandru Croitor2020-07-311-7/+49
| | | | | | | | | | | | | | | 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>
* CMake: Fix building debug apps with qmake on WindowsAlexandru Croitor2020-07-291-36/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 06557312d2a030f9ff771488bd6c97690a125a3d Task-number: QTBUG-85240 Change-Id: I413b705bc69732b0cbe1ee8cd089a1aef19365db Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix _nolink targets to be optional on the consumer sideAlexandru Croitor2020-07-291-11/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cmake: Add LOWDPI option to match CONFIG+=testcase_lowdpiTor Arne Vestbø2020-07-241-1/+9
| | | | | Change-Id: I8bcabf41ed353ec4e940a8fcea5b698e0ddf278f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Avoid enabling of "warnings_are_errors" flags for testsAlexander Volkov2020-07-231-1/+1
| | | | | | | | Change added dep in qt_add_cmake_library(): PlarformModuleInternal -> PlatformCommonInternal. Change-Id: I303a6a520f0dda7260b12cb21673b8f1a23d536b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* testlib selftest: Don't pass TESTARGS to Catch2Tor Arne Vestbø2020-07-231-2/+6
| | | | | | | It doesn't understand the arguments we usually pass to testlib. Change-Id: Iea83d1d8c31a510b2bc442cbfc810eac631322e7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix QT_STAGING_PREFIX for repos other than qtbaseJoerg Bornemann2020-07-131-0/+6
| | | | | | | | | | | | | 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>
* CMake: Fix incorrect SIMD arch_haswell and avx profile conditionsAllan Sandfeld Jensen2020-07-091-5/+40
| | | | | | | | | | | | | | | | | | | | 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>
* CMake: Fix missing qdevice.pri values and qt.conf info for AndroidAlexandru Croitor2020-07-091-2/+29
| | | | | | | | | | | | | | | | 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>
* CMake: Introduce QT_STAGING_PREFIXJoerg Bornemann2020-07-091-10/+2
| | | | | | | | | | | 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>
* CMake: Write EXTRA_RPATHS to qmodule.pri if QT_EXTRA_RPATHS is setJoerg Bornemann2020-07-071-0/+5
| | | | | Change-Id: Icd13cc047a9ca33f2ec9b6c2ce8216cbc4ae378b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't propagate private defines for Qt header modulesAlexandru Croitor2020-07-051-7/+15
| | | | | | | | | | | | 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>
* CMake: Write QT_CPU_FEATURES to qmodule.priJoerg Bornemann2020-07-021-1/+17
| | | | | | | | | | | 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>
* Limit OpenGL deprecation silencing on Apple platform to Qt itselfTor Arne Vestbø2020-07-021-5/+0
| | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Fix non-prefix build detection when CMAKE_STAGING_PREFIX is setJoerg Bornemann2020-07-011-3/+12
| | | | | | | | | | | | | | | | 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>
* CMake: Fix qconfig.cpp for cross-buildsJoerg Bornemann2020-07-011-21/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Enable bitcode when targeting UIKIT aka iOSAlexandru Croitor2020-07-011-3/+7
| | | | | | | | | | | | | | | | | 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>
* CMake: Use non-sanitized plugin type names in .pri filesAlexandru Croitor2020-07-011-2/+10
| | | | | | | | | | | | | | | 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>
* CMake: Specify Prefix in target_qt.conf for non-prefix buildsAlexandru Croitor2020-07-011-0/+3
| | | | | | | | | | | | | | | | | 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 d7fd6848612760124871f0f3b55917250d078dd5 Task-number: QTBUG-85240 Task-number: QTBUG-84781 Task-number: QTBUG-82581 Change-Id: I288a6e76a21d779a7e03443777f8a4ce28df9974 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix top-level .prl file generationAlexandru Croitor2020-07-011-20/+51
| | | | | | | | | | | | | | | | | | | | 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 8c8c0f65e322f6599bfe0e7d0752c386f1275bd5 Amends dde11715d357f95370850f5e4eebebcbe7964fb3 Task-number: QTBUG-84874 Fixes: QTBUG-84917 Change-Id: Id95b4cb7a0887c52f35c40bfdb96ad4a68dd6794 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Adjust some status messages about syncqt and file generationAlexandru Croitor2020-06-301-0/+1
| | | | | | | | | | | 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>
* CMake: Don't use libraries in /usr/local by default on macOSAlexandru Croitor2020-06-291-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Generate qdevice.pri when cross-buildingJoerg Bornemann2020-06-291-0/+22
| | | | | | | | | | | | | 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>
* CMake: Allow to pass a custom target mkspec nameJoerg Bornemann2020-06-291-11/+14
| | | | | | | | 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>
* CMake: Write host architecture and ABI to qconfig.priJoerg Bornemann2020-06-291-2/+17
| | | | | | | ...when cross-building Qt. Change-Id: I7d2fe83167fc278fde9f0c0fd70f5fa42fa62862 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Write gcc sysroot flags to qconfig.priJoerg Bornemann2020-06-291-15/+26
| | | | | | | | | | | | | 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>
* CMake: Support cross-compilation with qmakeJoerg Bornemann2020-06-291-2/+89
| | | | | | | | | | | | | 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>
* CMake: Transform absolute library paths into link flags in .pri filesAlexandru Croitor2020-06-291-3/+20
| | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Let qt_copy_or_install set the executable bit for PROGRAMSJoerg Bornemann2020-06-281-1/+20
| | | | | | | | | | | | 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>
* CMake: Add meta-target host_tools to easily build just the toolsAlexandru Croitor2020-06-261-0/+7
| | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-30 22:12:52 +0000