summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Fix double-negation of feature CONFIG valuesJoerg Bornemann2020-06-291-1/+5
| | | | | | | | | The plugin-manifests feature has the "negative" CONFIG value "no_plugin_manifest". On negation, we're supposed to strip off the leading "no_" instead of adding another one. Change-Id: Id2c66da41f22881272d5b923f12b85d9fcc2c9d0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Mark all find_package(PkgConfig) to be quietAlexandru Croitor2020-06-2921-21/+21
| | | | | | | | | This reduces the amount of warning messages when the pkg-config feature is disabled. Task-number: QTBUG-85276 Change-Id: I11a6dfb6273a1e48c47d1ef5c1a5f70ba990fbc0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Transform absolute library paths into link flags in .pri filesAlexandru Croitor2020-06-292-3/+106
| | | | | | | | | | | | | | | | | | | | | | | 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: WrapOpenGL target should also link AGL on macOSAlexandru Croitor2020-06-291-0/+9
| | | | | | | | | | This is consistent with the qmake mkspec in common/mac.conf Task-number: QTBUG-85240 Task-number: QTBUG-84781 Change-Id: I99df365a3be541356482d29eda806020f4e298d9 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Create a Find module wrapper for OpenGLAlexandru Croitor2020-06-291-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | Our .prl files embedded an absolute path to the OpenGL.tbd file. This obviously breaks their usage when used on another machine when no SDK exists. To fix that we need to use a "-framework OpenGL" linker flag instead of linking against the absolute path library. To convince CMake to do that, we have to create a wrapping OpenGL target which sets an appropriate INTERFACE_LINK_LIBRARIES property. So create a FindWrapOpenGL find module to do that on darwin platforms. Adjust helper.py and our build system to use it. This tangentially amends 38cd18384f6198c5bc3ea1da9ffc0158e960a778 because it recreates the FindWrapOpenGL module, but for a different purpose. Task-number: QTBUG-85240 Task-number: QTBUG-84781 Change-Id: I3498c19157ae31db5099e6edfb9d71490187f1d3 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: Create Qt6HostInfo packageJoerg Bornemann2020-06-282-0/+34
| | | | | | | | | | | | This package is supposed to be loaded when cross-building Qt from the host Qt installation prefix. It provides information about the host Qt by setting various variables. The information reflects what "qmake -query" of the host Qt would return. All provided variable names begin with "QT6_HOST_INFO_". Change-Id: Id568923a318d6e3b48c450663519a3727f615a8f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Display found information in some of the Find modulesAlexandru Croitor2020-06-2611-0/+31
| | | | | Change-Id: I5d92f2f1a552888361a2939577c2b0177c62b596 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix some incorrectly included FindPkgConfig modulesAlexandru Croitor2020-06-264-4/+4
| | | | | | | | This gets rid of a few warnings during configuration. Task-number: QTBUG-85276 Change-Id: I07d2fdfd8d3f81f1d780528ee6350e1a3ded9523 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Make more inner find_package calls quietAlexandru Croitor2020-06-264-6/+6
| | | | | | | Task-number: QTBUG-85276 Change-Id: I8ed84e2f2cdaf90224452a5e5a549791574edc15 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Add meta-target host_tools to easily build just the toolsAlexandru Croitor2020-06-262-0/+14
| | | | | | | | | | | 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: Pick up custom Info.plist in user projectsTor Arne Vestbø2020-06-261-2/+2
| | | | | | | | We can't rely on the MACOS define as that's set by our private QtPlatformSupport.cmake that's not shipped. Change-Id: I86c578a282a0833408a06d923954510a3579bdaa Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Match tense of other log outputTor Arne Vestbø2020-06-261-1/+1
| | | | | Change-Id: Ied164c97bd54f6b37450d7a2cf8225ee5190ce17 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Apply symbol visibility settings to Objective-C/C++ sourcesTor Arne Vestbø2020-06-252-0/+8
| | | | | | | | | | | | | | | 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>
* Raise the Android SDK build requirement to lvl 28 - compile fixAlex Blasche2020-06-231-1/+1
| | | | | | | | | | | | | | | First of all cmake and qmake used a different standard. Secondly, the qmake logic enforced lvl 23 (if it was installed which is the case on the failing machine). When this is combined with f71a400bf61 which requires lvl 28 API to build, the android build fails to compile. cmake logic was even worse as it enforced lvl 21 API to be used if installed. This change requires pick to 5.15 as f71a400bf61 was picked as well. Pick-to: 5.15 Change-Id: I89a7193b711b8bf927d02907343a49d6f27082ce Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@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>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-07 23:58:59 +0000