summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* Move QTextCodec support out of QtCoreKarsten Heimrich2020-06-201-68/+0
| | | | | | | | | | * Assume UTF-8 on all Unix like systems * Export some functions to be able to compile QTextCodec once moved to Qt5Compat. Task-number: QTBUG-75665 Change-Id: I52ec47a848bc0ba72e9c7689668b1bcc5d736c29 Reviewed-by: Lars Knoll <lars.knoll@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: Improve automatic compiler embedding into the Qt toolchainAlexandru Croitor2020-06-181-4/+42
| | | | | | | | | | | | | | | | | Embedding the initial CMAKE_CXX_COMPILER into qt.toolchain.cmake breaks Boot2Qt builds, because the CXX environment variable is not used anymore when building qtsvg or other projects. Disable automatic embedding when cross-compiling, while keeping it enabled for non-cross-compiling cases (to keep Windows and and ICC configurations working). Allow opting in or out of the embedding in case if the default is wrong, via QT_EMBED_TOOLCHAIN_COMPILER. Task-number: QTBUG-85067 Change-Id: I1d8f9f580bc379b77c34eefb5728bb49f93cc81a Reviewed-by: Joerg Bornemann <joerg.bornemann@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-172-0/+34
| | | | | | 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-172-0/+37
| | | | | | | | 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-162-2/+35
| | | | | | | | | | | | | | | 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: Do not use $$[QT_INSTALL_LIBS/get] in generated .prl filesJoerg Bornemann2020-06-161-2/+2
| | | | | | | | | We do not support building with qmake from the build directory in prefix builds. Therefore we can just use the standard QT_INSTALL_LIBS property instead of the /get variant. Change-Id: I82ccaf1894fb1dccc9ec18b4984b582b555ce0f8 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-153-0/+38
| | | | | | | | | | | | | | | 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-152-8/+35
| | | | | | | | | 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-122-6/+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: Propagate largefile flags to all internal consumersAlexandru Croitor2020-06-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The large file flags in qmake land are set in the mkspecs/features/unix/largefile.prf file, which is loaded by qmake when a CONFIG += largefile entry is written by configure into qmodule.pri. This essentially makes them global flags for all private Qt targets because qmodule.pri is a global file loaded load(qt_build_config) Thus assign the flags onto the PlatformCommonInternal target instead of the PlatformModuleInternal one. One peculiarity though is that in qmake land these flags are also applied when building examples as part of the main Qt build. This is because qt_build_config loads qmodule.pri even for an example, because qmake sees it as part of the overall Qt build. The flags are not applied by qmake if the example is built in a different standalone build dir not part of the Qt buil dir. We don't do that in the CMake build, and thus examples will never have those flags. Task-number: QTBUG-83929 Change-Id: If653a669b4835aadd1de84acb477c375ab523909 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>
* Remove last traces of QT_BUILD_EXAMPLESKai Koehne2020-06-111-9/+1
| | | | | | | | Amends dc1dd51af3a35728235cb63a31b07ff76a652208 Task-number: QTBUG-84471 Change-Id: Ia525398aea4d90ac57c0f567ac8b48bf5ce80fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Do not generate qtbase/bin/qt.confJoerg Bornemann2020-06-112-23/+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: Don't add "d" suffix to MinGW debug librariesJoerg Bornemann2020-06-111-1/+9
| | | | | | | | | | To be in line with the qmake build we drop the "d" suffix for MinGW debug libraries unless the debug_and_release feature is enabled. Task-number: QTBUG-84781 Change-Id: I1b83492bff561d3d7647dde467931ec3866ae940 Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix incorrect paths in build instructions messageAlexandru Croitor2020-06-111-4/+4
| | | | | | | | | | | | | When doing a top-level build, QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX is not set in the top-level scope. There's no point really in using the relocatable path anyway, given this will only be displayed once when either configuring qtbase or qt6. Just use CMAKE_INSTALL_PREFIX directly. Change-Id: Idb7e1953745f55048c42155868c2dd9384876c7c Reviewed-by: Cristian Adam <cristian.adam@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: Don't configure examples by defaultAlexandru Croitor2020-06-101-1/+1
| | | | | | | | | Users / developers usually configure a single example. The CI can still continue to explicitly configure and build all examples. Task-number: QTBUG-84471 Change-Id: I1c9ac857e7ad0e5602037265194f0a6742386b51 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix dbus duplicate target errors in top-level buildsAlexandru Croitor2020-06-101-1/+4
| | | | | | | | | | | | | Fixes the 'add_library cannot create imported target "dbus-1" because another target with the same name already exists' error when doing top-level static builds. It's caused by the loading of Qt6DBus dependency when configuring qttools. Task-number: QTBUG-84874 Change-Id: Ia84ed460c4ce25de45fb41cb13edd0e63a276f11 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix libraries in qt_lib_XXX_private.pri files for NMCJoerg Bornemann2020-06-093-31/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: Save OPENSSL_ROOT_DIR in QtBuildInternalsExtraAlexandru Croitor2020-06-081-0/+10
| | | | | | | | | | | This is needed so that other repos other than qtbase (like qtopcua) can still find_package(WrapOpenSSL) successfully. The path needs to be converted to a CMake path, to avoid issues on Windows with backslashes. Change-Id: I3d7652d93110f6b8f39a58a6c28aef6c7471aea7 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Don't reset install prefix upon standalone test reconfigurationAlexandru Croitor2020-06-081-12/+4
| | | | | | | | | | | | | | | | | | | | CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT might be empty on the first configuration, but because QtBuildInternalsExtra sets the CMAKE_INSTALL_PREFIX, a second reconfiguration of a test would stop setting the fake install prefix. After some further consideration, there's no need to set the local fake prefix conditionally, we can always do it (unless explicitly opted out). This makes sure that a reconfiguration of a test doesn't suddenly install into the Qt prefix again. Amends 37b132cd4e081821ddc261d24abe8f914123547a Task-number: QTBUG-84346 Change-Id: Ic61aefe18418658455d8cdb9ebe6bcbcb8d67c99 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Do not create Qt6ToolsConfig[Version].cmake filesJoerg Bornemann2020-06-082-54/+0
| | | | | | | | They are not necessary, and they conflict with what qttools generates. Fixes: QTBUG-82133 Change-Id: I4a1273d694626345b32b45c653dd31d3b78621eb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: quote paths to prevent issues when no install prefix is setJean-Michaël Celerier2020-06-051-1/+1
| | | | | Change-Id: Ifa7f1ef70c4893e10cb4ce9a54d8a0806d19be93 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Clean up AND NOT QT_BUILD_STANDALONE_TESTS in QtAutoDetectAlexandru Croitor2020-06-041-3/+2
| | | | | | | | Now that the whole file is not included when doing standalone tests, the conditions are not needed anymore. Change-Id: I49ddd2fc4a8327e09529948785f40cda5dedbb11 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Protect against Qt toolchain file recursive inclusionAlexandru Croitor2020-06-043-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | Three different people have encountered the issue that calling calling qt-cmake on a project prints 1000 inclusion lines of the same qt toolchain file, and then CMake bails out saying can't find the CMAKE_MAKE_PROGRAM Ninja. This happened because people accidentally called qt-cmake to configure qtbase (instead of just cmake), which created a toolchain file that chainloads itself recursively. Error out when configuring qtbase, and when using the generated toolchain file in the case when it would try to include itself. The solution is to remove the qtbase CMakeCache.txt file, and configure qtbase again, so it generates a proper qt.toolchain.cmake file. If somebody feels enthusiastic, they can move the check into the qt-cmake and qt-cmake-private shell scripts, and error out before the qtbase/CMakeCache.txt is polluted with the wrong toolchain file. That is left for people that feel more comfortable with bash and batch scripting. Change-Id: If518c94791fe7c30731e6e462e347f26a5213c64 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix qmake mixing for framework buildsAlexandru Croitor2020-06-042-6/+23
| | | | | | | | | | | | | 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 double-conversion usage on macOSAlexandru Croitor2020-06-041-37/+3
| | | | | | | | | | | | | | | | | | We reported that double-conversion was found on macOS if the std library supported sscanf_l and _snprintf_l, but that's different from what qmake does. This caused not to compile and link the bundled double-conversion sources, and caused tst_qvariant to fail when doing double conversions on macOS. Remove the extra config tests, and make it work like in qmake, so that the bundled code is used instead. This makes tst_qvariant pass. Amends 729a73a9cfe774cb49251be8c99ba5b26d516e01 Change-Id: I7ddaed5fe6916f483fb3de1962657d7fb6fb40be Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix standalone tests to work properly on reconfigurationAlexandru Croitor2020-06-043-17/+33
| | | | | | | | | | | | | | | | | And also fix qt-cmake-standalone-test to work for prefix builds. The gist of it is that we have to protect tests not to be installed into the Qt install prefix, but we also have to make sure that the CMAKE_INSTALL_PREFIX is not changed globally (via cache value), so that reconfiguration still works. This took way too long to figure out. Amends d6272d774c7415186aa398e59f234d0073458072 Fixes: QTBUG-84346 Change-Id: I18c29574c9957fe05b86f701c8c14ec07e0f045b 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-024-23/+108
| | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-01 09:18:24 +0000