summaryrefslogtreecommitdiffstats
path: root/cmake/QtBuild.cmake
Commit message (Collapse)AuthorAgeFilesLines
...
* 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>
* CMake: Fix framework handling for .pri filesAlexandru Croitor2020-06-261-1/+5
| | | | | | | | | | | | | | | | | | | | | | | 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 c254254c55b24dd0653331e025cdfdbbdcca2a56 Task-number: QTBUG-85240 Task-number: QTBUG-84781 Change-Id: I70ea5021422d7b1f5afa9c4a595d1a9b8a8217d3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Apply symbol visibility settings to Objective-C/C++ sourcesTor Arne Vestbø2020-06-251-0/+6
| | | | | | | | | | | | | | | 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>
* CMake: Place framework .prl files under ResourcesAlexandru Croitor2020-06-251-0/+8
| | | | | | | Adapts to qmake's 74abe983204dab35dcce59001308c54d34ad2c02 change Change-Id: If1d6ce063d53dda4835a224661a16219cf9a9476 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow specifying custom configure.cmake file for moduleAlexandru Croitor2020-06-231-1/+4
| | | | | | | | | | | 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>
* CMake: Fix include paths for AUTOMOC when using frameworksAlexandru Croitor2020-06-231-17/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Do not file(GENERATE) illegal genexes in .pri file generationJoerg Bornemann2020-06-191-0/+5
| | | | | | | | | | | | | | | | | 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>
* CMake: Query public target defines when generating module .pri filesAlexandru Croitor2020-06-181-5/+6
| | | | | | | | | | | | | | | 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 3452b08df6a3802c96b06651f9a530d55cbe7477 Task-number: QTBUG-84781 Task-number: QTBUG-84881 Change-Id: Ide68ecf3f89be6d5462cfe43706c27f9cb53394f Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix namespace builds for qmake mixingAlexandru Croitor2020-06-181-1/+6
| | | | | | | | | | | | | | | | | 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 3452b08df6a3802c96b06651f9a530d55cbe7477 Task-number: QTBUG-84781 Task-number: QTBUG-84881 Change-Id: I3175aa9991a06a4541eb0dd153ba2e6e58c019ce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Use intelcet flags for bootstrap and qmakeAlexandru Croitor2020-06-181-0/+19
| | | | | | | | | This should fix build failures on Ubuntu 20.04. Amends fa98adbd04de9d44ce921436b92589a41f285dcd Change-Id: Iff399faff0cf06f5b88d756b1f632b8798069578 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't use a lib prefix for MinGW prl filesAlexandru Croitor2020-06-181-1/+7
| | | | | | | This is to be consistent with qmake. Change-Id: I17b8a3e4649d035d1d871e4f124952cded7f6664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Improve .prl dependency trackingAlexandru Croitor2020-06-181-3/+20
| | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Simplify the qt_path_join functionJoerg Bornemann2020-06-171-6/+1
| | | | | | | Use ARGN that already has the out_var parameter removed. Change-Id: I79438caa4333a11493456fa219448ad500518880 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix .prl generation and installation for pluginsJoerg Bornemann2020-06-171-4/+4
| | | | | | | | | | | | | | | | | | | 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 8c8c0f65e32. Task-number: QTBUG-84781 Change-Id: I7188b799716576b3296ee7b2d460489867b9967a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix MinGW prefixes / suffixes againAlexandru Croitor2020-06-171-6/+29
| | | | | | | | | | | | | | 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 f626c73b28b52ecf3a3fb20592f2134337f89d35 and 9b0e23ef8a915a8c58808fa356f771ecdb6f020c Task-number: QTBUG-84781 Change-Id: I059db13f8d8a0aab8bd3fc69d4537a2b63687394 Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Write QT_MAC_SDK_VERSION into qconfig.priAlexandru Croitor2020-06-171-0/+4
| | | | | | Task-number: QTBUG-84781 Change-Id: I9f4e979a7404dd45286e0a85a6f3772e53a2fd0b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Add additional info which was missing in qconfig.priAlexandru Croitor2020-06-171-0/+36
| | | | | | | | Mostly compiler version numbers. Task-number: QTBUG-84781 Change-Id: I10e92fdfd4e603c9b763a51a0e09b6c4a2c75ac7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Record info about namespaced build for qmakeAlexandru Croitor2020-06-171-0/+9
| | | | | | | | | 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>
* CMake: Fix usage of qt_process_qlalr when cross compilingAlexandru Croitor2020-06-171-0/+6
| | | | | | | | | | | 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>
* CMake: Write object libs of Qt resources to .prl filesJoerg Bornemann2020-06-161-1/+29
| | | | | | | | | | | | | | | Since commit e343affd634 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>
* CMake: Fix many failing qtdeclarative MinGW testsAlexandru Croitor2020-06-151-8/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 c33916a279ef5908e1ebd44644c873933f6a7c77 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 9b0e23ef8a915a8c58808fa356f771ecdb6f020c. 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 9b0e23ef8a915a8c58808fa356f771ecdb6f020c 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>
* CMake: Improve sanitizer detectionAlexandru Croitor2020-06-151-0/+32
| | | | | | | | | | | | | | | 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>
* CMake: Generate .prl files for plugins in static Qt buildsJoerg Bornemann2020-06-151-4/+28
| | | | | | | | | 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>
* CMake: Make GL_SILENCE_DEPRECATION a public define for all consumersAlexandru Croitor2020-06-121-0/+5
| | | | | | | | | | | | 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 17be43c58ec6fbffee52d2a64038c4744610875a Task-number: QTBUG-83929 Change-Id: I9f9d7dfca24b54977cb8364723c3618d3fec2e73 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix usage of gc_binaries featureAlexandru Croitor2020-06-121-4/+21
| | | | | | | | | | | | | | | | 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>
* CMake: Add missing QT_USE_QSTRINGBUILDER define for toolsAlexandru Croitor2020-06-121-1/+3
| | | | | | | | This mirrors what qt_tool.prf does. Task-number: QTBUG-83929 Change-Id: I892a3f5f62d461456abfa414718fcc4c4c05c012 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix default TARGET_DESCRIPTION for Qt toolsJoerg Bornemann2020-06-121-1/+8
| | | | | | | | | 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>
* CMake: Do not generate qtbase/bin/qt.confJoerg Bornemann2020-06-111-22/+0
| | | | | | | | | | | | | | | | | | 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>
* CMake: Implement workaround for failing linux static buildsAlexandru Croitor2020-06-111-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Rename cpp compile check to HAVE_DASH_UNDEFINED_SYMBOLSAlexandru Croitor2020-06-111-3/+3
| | | | | | | | | | | | 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>
* CMake: Fix installation location of plugins in static builds of QtJoerg Bornemann2020-06-111-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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 b42feb02cee 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>
* CMake: Temporary workaround for static top-level Qt buildsAlexandru Croitor2020-06-101-1/+7
| | | | | | | | | | | | | | | | | 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>
* CMake: Fix libraries in qt_lib_XXX_private.pri files for NMCJoerg Bornemann2020-06-091-31/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Fix qt_lib_XXX_private.pri generation for internal modulesJoerg Bornemann2020-06-091-15/+19
| | | | | | | | | 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>
* CMake: Fix failing plugin tests on MinGWAlexandru Croitor2020-06-091-0/+4
| | | | | | | | | | | 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 9b0e23ef8a915a8c58808fa356f771ecdb6f020c Change-Id: I1cfaf8fc046f86edd3e755adfa599aa0aa854ee3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix qmake mixing for framework buildsAlexandru Croitor2020-06-041-5/+22
| | | | | | | | | | | | | 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>
* CMake: Fix tst_foo_check to work for qml tests as wellAlexandru Croitor2020-06-031-6/+10
| | | | | | | | | | | | | | | 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 873aa682c56b1c187e2c87b49050509db9d1b16b Change-Id: Ic8bbfe668c00c1ce05f1e1dfe5494dafd91dd7b8 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* CMake: Make it possible to build tools when cross-compilingLeander Beernaert2020-06-021-19/+78
| | | | | | | | | | | | | | | | | | | 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>
* CMake: Add ${tst_foo}_check target for easy test runningAlexandru Croitor2020-06-021-0/+8
| | | | | | | | 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>
* cmake: Quote the arguments to CMD's 'set' commandMårten Nordheim2020-05-291-1/+1
| | | | | | | This avoids issues with some special characters and spaces. Change-Id: I6b7cedbe2c9663f62fae104488454faebab52ce0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake Build: Do not set "lib" prefix for modules (plugins)Cristian Adam2020-05-291-0/+4
| | | | | | | CMake sets "lib" as default prefix for Windows-GNU platforms. Change-Id: I49e3123c385610307c84c584a21f5f3827a6fafd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 16:35:30 +0000