summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Fix line endings of wrapper scriptsJoerg Bornemann2022-05-172-11/+23
| | | | | | | | | | | | | | | If QT_GENERATE_WRAPPER_SCRIPTS_FOR_ALL_HOSTS is ON then we generate Windows scripts on Unix and vice versa. We always used the host platforms line endings for generating the scripts. This leads to Windows line endings in Unix scripts and vice versa. Explicitly specify the line endings style when generating wrapper scripts. Fixes: QTBUG-102747 Pick-to: 6.2 6.3 Change-Id: I1603add46f276a5d91bbf0f103a261cdd84c343b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-162-76/+4
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix static library link order when using qmakeAlexandru Croitor2022-05-122-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | qmake adds QMAKE_PRL_LIBS values on the link line after the currently processed library. Because CMake adds resource object files into QMAKE_PRL_LIBS, they end up on the link line after the library. This causes issues on Linux with GNU ld and ld.gold, because the linker discards symbols from the library which are then later referenced by the object files. Work around that by placing the path to the library directly into QMAKE_PRL_LIBS after the resource object files. This ensures the linker doesn't discard the symbols required by the resource object files. This means that each library encountered in qmake's LIBS variable will be temporarily referenced twice in qmake's project state: once from LIBS / QMAKE_PRL_TARGET, and once when the QMAKE_PRL_LIBS values are added. On the link line it will appear only once though, because qmake does library deduplication during prl file processing, which only keeps the last occurrence. Amends 4ab54320817ebbb465af343514d21139a654aed3 Pick-to: 6.2 6.3 Fixes: QTBUG-103002 Change-Id: I97647b64de22b158424850915fee62b5fea5f995 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Use full file path for the generated dbus filesAlexey Edelev2022-05-121-2/+8
| | | | | Change-Id: Idb7cb49800eaef4a2e09d3e03d2e44528d992d75 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* wasm: enable WASM_BIGINTMorten Sørvig2022-05-121-1/+2
| | | | | | | | | | | | | | | | | | | JavaScripts's BigInt feature provides support for arbitrary-precision integers. This makes it possible to represent 64-bit integers; the standard JS Number type supports 32-bit integers only (or more accurately 53-bit integers - see Number.MAX_SAFE_INTEGER). Enable WASM_BIGINT which makes Emscripten map int64_t and uint64_t to BigInt when interfacing with JavaScript code. This removes one of the conditions which enables wasm-emscripten-finalize. Task-number: QTBUG-103352 Change-Id: Ia70d599daaf34c92695f5a2b61665e0c237e6b95 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Lorn Potter <lorn.potter@gmail.com> Reviewed-by: David Skoland <david.skoland@qt.io>
* wasm: set ASSERTIONS level to default (1)Morten Sørvig2022-05-121-1/+0
| | | | | | | | | | This removes one of the conditions which enables wasm-emscripten-finalize. Task-number: QTBUG-103352 Change-Id: Id05db4b081dec360cdad2e611622e5baf09aeb23 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: David Skoland <david.skoland@qt.io>
* Hardcode atomic_LIB as -latomicDmitry Shachnev2022-05-121-1/+1
| | | | | | | | | | | | | find_library does not always work because libatomic.so may be in a path like /usr/lib/gcc/x86_64-linux-gnu/11/libatomic.so, which CMake does not consider by default. Pick-to: 6.3 Change-Id: I73a657c470efa4f84f8629bd531edfcac3b3a352 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Handle strip wrapper creation more robustlyAlexandru Croitor2022-05-111-11/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unsetting CMAKE_STRIP and including CMakeFindBinUtils to find it again is not safe, because CMakeFindBinUtils has logic to search for additional tool names depending on the currently processed language. The currently processed language is set in _CMAKE_PROCESSING_LANGUAGE only when CMake is doing it's language introspection via CMakeCXXCompiler.cmake. This resulted in the build system finding a regular host-OS strip, rather than an android specific llvm-strip when doing an Android build, which then silently failed to strip the Android libraries and caused us to ship big binaries. Improve the strip wrapper creation in a few ways: - Save the original strip value on first configuration - Restore it if needed, without using CMakeFindBinUtils - Don't apply the strip wrapper creation logic to Android, we currently don't need it there - Add some informational messages about which CMAKE_STRIP ends up being used even if log-level is not DEBUG - Fix a typo Amends 39f657032b5e65bfcb93472201f6607c0388ba37 Pick-to: 6.2 6.3 Fixes: QTBUG-103356 Task-number: QTBUG-101653 Change-Id: I23d98180446d5bb7628e783668f46e4e546ed700 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix initialization of QT_BUILD_TOOLS_BY_DEFAULTJoerg Bornemann2022-05-112-7/+8
| | | | | | | | | | | | | | ...when QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON. When QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON, we want to set QT_FORCE_BUILD_TOOLS. But this happened too late: after the initialization of QT_BUILD_TOOLS_BY_DEFAULT. This value depends on QT_FORCE_BUILD_TOOLS. This amends commit acfbe3b7795c741b269fc23ed2c51c5937cd7f4f. Change-Id: Ibdba54da943aea1b55618f10d2b8485f4390878a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make possible building Qt tools without the use of core libraryAlexey Edelev2022-05-063-19/+25
| | | | | | | | | | | | | | Replace BOOTSTRAP option with the single value CORE_LIBRARY argument in qt_internal_add_tool and qt_internal_add_executable functions. The introduced argument now may accept 'Bootstap' and 'None' values. Use 'Bootstap' to link Qt::Boostrap library instead Qt::Core or 'None' to avoid any core library linking. This is useful for tools that need to use the CMake deployment routines, but not require the Qt::Core functionality. Task-number: QTBUG-87480 Change-Id: I64a8b17f16ac5fe43c6b385252dc21def0c88d2c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: also allow building tools when found elsewhere in host buildsThiago Macieira2022-05-045-26/+48
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, this was only supported when cross-compiling, but that's an unnecessary limitation. Instead, make it possible to build the "host" tools (notably qmake) even when they've been found elsewhere due to QT_FORCE_FIND_TOOLS=ON and a supplied QT_HOST_PATH. The combination of QT_FORCE_FIND_TOOLS and QT_FORCE_BUILD_TOOLS set to ON is useful for developers who touch content that ends up in the bootstrap library. QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is deprecated in favor of QT_FORCE_BUILD_TOOLS. [ChangeLog][CMake] QT_BUILD_TOOLS_WHEN_CROSSCOMPILING has been deprecated in favor of QT_FORCE_BUILD_TOOLS. The latter can be used in combination with QT_FORCE_FIND_TOOLS and QT_HOST_PATH to use tools from a host Qt even for a non-cross build and still build the tools. Fixes: QTBUG-99683 Change-Id: I0e5f6bec596a4a78bd3bfffd16c8fb486181f9b6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* CMake: Fix typo in error messageJoerg Bornemann2022-05-021-1/+1
| | | | | | Pick-to: 6.2 6.3 Change-Id: Iace4fe19c0bdbcb61f667363d86b22abf6ec7d24 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add qpa include directory to the return values of qt_internal_module_infoAlexey Edelev2022-05-021-1/+16
| | | | | Change-Id: I0540ce70e4a5dbde4027d97d9308c61248230c96 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Pass compilers on to examples configsAllan Sandfeld Jensen2022-04-261-0/+4
| | | | | | | | Otherwise they will just use default compiler Pick-to: 6.3 Change-Id: Id5813b99fbbb6b0d8b0ee658e06312b637a097c1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Handle detection of linux-g++-32 mkspecAlexandru Croitor2022-04-252-0/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If Qt is configured with -platform linux-g++-32 , make sure to add the -m32 compile options for all built targets. On 64 bit host OSes that provide both 32 and 64 bit libraries we need to exclude the 64 bit libraries from being picked up. The locations of the libraries are distro-specific. This change by default excludes the Ubuntu x86_64 libraries paths. Opt outs are provided, which when used, forces Qt builders to specify their own ignore paths in a custom CMake toolchain file. The compile option and default path exclusions are added to the Qt-generated CMake toolchain file as well, so they are reused when building other Qt repositories. Note that there is no foolproof way to tell CMake to ignore all x86_64 packages / libraries, even if CMake 3.23 CMAKE_IGNORE_PREFIX_PATH is used, because there might not be a single sysroot to exclude. Both x86 and x86_64 libraries can co-exist in the same sysroot, e.g in /usr One would have to list each package / library directory in CMAKE_IGNORE_PATH manually. Additionally, the PKG_CONFIG_LIBDIR environment variable is also set to Ubuntu specific prefixes, to ensure that pkg_check_modules -> pkg-config don't pickup x86_64 libraries. Fixes: QTBUG-101963 Change-Id: Ib17c8d2cd0ba33b2cf748772245bcd558de9120c Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* zlib as static libraryKai Köhne2022-04-222-29/+40
| | | | | | | | | | Do build zlib as static 3rdparty library. This makes it easier to disable warnings. Pick-to: 6.3 Change-Id: I1db331b671b64e68d81c56b0df337983c3bbe7fa Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix interleaved configure outputAlexandru Croitor2022-04-221-0/+5
| | | | | | | | | | | | | | | | | | | message(STATUS) prints output to a buffered stdout, whereas message(NOTICE) or just message() print to unbuffered stderr. We use a mix of message() calls when printing the configuration summary, which caused interleaved output. Because CMake offers no message(FLUSH), we work around the issue by calling execute_process(COMMAND -E echo " ") which does call std::cout << s << std::flush; We seem to have to do it twice, before and after the detailed configuration summary is printed. Pick-to: 6.2 6.3 Change-Id: Ibc075551fc0547073f0696477e54d9b9c1edca97 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Embed an empty qt_prfxpath if Qt is relocatableAlexandru Croitor2022-04-221-5/+12
| | | | | | | | | | | | | | | | | | | When Qt is configured as relocatable, QT_CONFIGURE_PREFIX_PATH_STR -> qt_configure_prefix_path_str -> qt_prfxpath is not used in relevant code paths. Specifically qlibraryinfo.cpp getPrefix() uses getRelocatablePrefix() instead of QT_CONFIGURE_PREFIX_PATH. Thus, when Qt is configured as relocatable, set qt_prfxpath to an empty string. This avoids embedding a CI path like /home/qt/work/install into the official packages, which makes reproducible builds a closer reality. Change-Id: I9209b08e651ad0b7fdc4049df333e0978e05f1f5 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* CMake: Work around build rpath issue when CMAKE_STAGING_PREFIX is setAlexandru Croitor2022-04-226-1/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CMake has logic to rewrite build rpaths that contain CMAKE_STAGING_PREFIX to instead point to CMAKE_INSTALL_PREFIX. This breaks running executables from the build directory, because their build rpath will point to a location where the libraries might not exist yet (we didn't install Qt yet). Work around this by setting CMAKE_STAGING_PREFIX to a fake path, so that CMake does not do the rewriting anymore. CMAKE_STAGING_PREFIX needs to be set at subdirectory scope, not function scope, which is why qt_internal_apply_staging_prefix_build_rpath_workaround() is a macro that is called from within each Qt internal function that creates a target. The workaround can be disabled by configuring with -DQT_NO_STAGING_PREFIX_BUILD_RPATH_WORKAROUND=ON The downside of this workaround is that it breaks per-subdirectory install rules like 'ninja src/gui/install'. Regular global installation like 'ninja install' works fine. This is similar to what we do for tests in qt_set_up_fake_standalone_tests_install_prefix() introduced by 20292250d44e08437306096e9096fc655cc9fb8b The reason it's not as good for other target types is because in contrast to tests, we do want to install them. In case if someone does call `ninja src/gui/install' they will most likely get a permission error, telling them it's not possible to install into /qt_fake_staging_prefix/ check_qt_internal_apply_staging_prefix_build_rpath_workaround Fixes: QTBUG-102592 Change-Id: I6ce78dde1924a8d830ef5c62808ff674c9639d65 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* wasm: add specialHTMLTargets to EXPORTED_RUNTIME_METHODS for qmakeLorn Potter2022-04-211-0/+1
| | | | | | | | | | | The change 0ec75f4b9932a65f9ec7ec79eb6f2e04691cea3f missed adding specialHTMLTargets for qmake Also add warning to keep QtWasmHelpers in sync with qmake.conf Change-Id: Idb363e77f0cecb4f125d3cb4f7507899149a3bac Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* CMake: Disable CMAKE_INSTALL_RPATH_USE_LINK_PATHAlexandru Croitor2022-04-191-11/+9
| | | | | | | | | | There should be no need for CMake to add rpaths pointing to directories outside of the build tree to the installed libraries. All relevant install rpaths are handled by qt_apply_rpaths(). Change-Id: If554b1e3c790c2bb04a34e8b0524aab3febf5afc Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Fix implementation of qt_apply_rpathsAlexandru Croitor2022-04-191-14/+44
| | | | | | | | | | | | | | | | | | | | | | There were a few things that were not ported correctly. Make sure to disable rpath manipulation if the rpath feature is disabled. Fix if(IS_ABSOLUTE) conditions to actually take values. Don't embed bogus relative rpaths if the platform does not support it. QNX is such a platform, it does not support $ORIGIN (at least from my scouring of QNX documentation and manual testing via QEMU). Handle the extra rpath case where they are relative, but the platform does not support relative rpaths, by transforming them into absolute ones. Amends 67ee92f4d898ee76c40b7efd8e69782a6a4a3754 Change-Id: I04168633ec51b3cc5d580b738a7dc280fe6e0d2d Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Sync rpath documentation with the current implementationAlexandru Croitor2022-04-191-9/+25
| | | | | | Pick-to: 6.2 6.3 Change-Id: Id3af1cdfd66cd9527ab76137d72e354edfc3de75 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Print prefix info when building qtbaseAlexandru Croitor2022-04-191-0/+9
| | | | | | Pick-to: 6.2 6.3 Change-Id: Ib76d94b1c51f99d5ce007d463d97b5d2b256d2bf Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: An -extprefix -developer-build should install by defaultAlexandru Croitor2022-04-191-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously if -extprefix /tmp/sysroot (CMAKE_STAGING_PREFIX) -developer-build (FEATURE_developer_build) were specified, but -prefix (CMAKE_INSTALL_PREFIX) was not, the build system would set the CMAKE_INSTALL_PREFIX to the qtbase build dir. Then, if targeting desktop, this would be considered a non-prefix build (ninja install would refuse to work), whereas in a cross-build it would be considered an installable build. In both cases though, the rpath of installed binaries would point to the qtbase build dir (because CMAKE_INSTALL_PREFIX would be set to the qtbase build dir). This is quite confusing behavior, in more than one way. Change the build system to consider that an explicit -extprefix should cause Qt to always be installed, even if -developer-build is specified. This means the installed rpaths and on-device install prefix (CMAKE_INSTALL_PREFIX) will now use the default computed install prefix, e.g. /usr/local/Qt It also means that to get a non-installable developer + custom staging and install (on-device) prefix build, users will have to be explicit and set all the options -extprefix ~/qt/qtbase_build_dir -prefix /usr -developer-build Pick-to: 6.2 6.3 Change-Id: Ib560452a4b4778860e0fd7666c76f8a6745773ee Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow no install + custom on-device prefix for desktop buildsAlexandru Croitor2022-04-193-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow such a combination - staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the qtbase build dir - install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set to some custom location even for non-cross builds. An example would be configure -prefix /usr \ -extprefix ~/qt/qtbase_build_dir CMake will put the Qt libraries in the qtbase build dir, ninja install will not be required, but ultimately in order to run applications, the Qt libraries are expected to be in /usr. Support for this scenario was originally added for cross-builds in 062318feb2d3b7598409c7e81e4459c2f4607764 , but not desktop builds. Such a build is useful when you want to have install rpaths different from where Qt is initially installed to (the staging prefix). This case doesn't really happen often when targeting desktop platforms, it's mostly used for cross-compilation (e.g yocto). Being able to have the same setup with a desktop build is nevertheless useful for faster iteration on build system issues in such a scenario. Amends 062318feb2d3b7598409c7e81e4459c2f4607764 Pick-to: 6.2 6.3 Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* configure: Add newline between configure summary and build instructionsTor Arne Vestbø2022-04-191-1/+1
| | | | | | | | | | | | | Otherwise we get: Styles ................................. Basic Fusion Imagine iOS Material Universal macOS Windows -- Qt is now configured for building. Just run 'cmake --build . --parallel' Pick-to: 6.2 6.3 Change-Id: Ie8d009455e4f45c9eb0557c4a08e9d0a94030c3a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Explicitly check for atomic addition and relaxed load operation supportMoody Liu2022-04-181-15/+19
| | | | | | | | | | | | | ...and properly find and link against `libatomic` using find_library. This fixes the qtdeclarative build on the RISC-V platform. Initial-patch-by: Sprite <SpriteOvO@gmail.com> Pick-to: 6.2 Pick-to: 6.3 Task-number: QTBUG-99234 Change-Id: I2b5e4812886ce45cb02bed3106ce8c519b294cbe Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* wasm: use emscripten::val for specialHTMLTargetsLorn Potter2022-04-151-1/+1
| | | | | | | | | | | We need to add specialHTMLTargets to EXPORTED_RUNTIME_METHODS in order to use it, as Emscripten does not export it. Also, EM_ASM is not allowed for SIDE_MODULES, so it's better to use emscripten::val methods. Change-Id: I9b352ac98e2a961157f5bb36456bec3e35891270 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* wasm: remove SAFE_HEAP=1Morten Sørvig2022-04-131-1/+0
| | | | | | | | This adds significant run-time overhead and should not be on by default. Pick-to: 6.3 Change-Id: I33d312e31bd714f696d8acf2066eb4b285ff04af Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
* Suppress cmake warning about empty string argumentAlexey Edelev2022-04-121-1/+7
| | | | | | | | | | | | | | | When generating .pc files there is a warning when executing QtFinishPkgConfigFile.cmake: Ignoring empty string ("") provided on the command line. This happens because the 'postfix' argument is a part of the script command line even if it's empty. It also makes no sense to check if 'postfix' is empty using genex, use configuring-time check instead. Pick-to: 6.2 6.3 Change-Id: If52d9634f4885caefb828976b3c99592a6db3d3c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix check for pcre2 using cmakeJonas Kvinge2022-04-081-1/+1
| | | | | | | | | | | | | | When PCRE2 is compiled using cmake, a pcre2 cmake file is installed and Qt fails to configure because components isn't specified for find_package. In recent PCRE2 releases components needs to be specified for find_package. Fixes: QTBUG-102358 Pick-to: 6.2 6.3 Change-Id: Ib842b2c4b1c0bf38aa5da5475eaa2b3c56c6b822 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Map the 'verbose' configure option to CMakeAlexey Edelev2022-04-062-1/+3
| | | | | | | | Raise the CMake log level to STATUS when the 'verbose' argument is passed to the configure script. Change-Id: I736d95ab66b115f8416eec7f9e2ee96d1580c78d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Build system: Allow user to enable Intel CETYuhang Zhao2022-04-061-0/+15
| | | | | | | | | | | | | | | | | MSVC: https://docs.microsoft.com/en-us/cpp/build/reference/guard-enable-eh-continuation-metadata?view=msvc-170 https://docs.microsoft.com/en-us/cpp/build/reference/cetcompat?view=msvc-170 GCC: https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Instrumentation-Options.html Clang: Don't know where's the documentation but should use the same parameter with GCC. Change-Id: I654618e45743a5ad1394c930932b9d0044572725 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Reorganize work with graphical libraries on INTEGRITYTatiana Borisova2022-04-053-0/+33
| | | | | | | | | | | | - Currently we manually unpack all platform libraries, that are required for GUI apps, and pack it into single eglmegapack.a library. It could be better do not execute such additional step, but have possibility to add required graphical libs to cmake interface lib via toolchain file list variable. Pick-to: 6.2 6.3 Change-Id: Ic4122600f02e6828d528ee4f00075f8c27f42e38 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow specifying custom install dir for non-EP examplesAlexandru Croitor2022-04-041-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, QT_INTERNAL_EXAMPLES_INSTALL_PREFIX was added to control the installation of examples when they are built as ExternalProjects, and was not considered for the non-EP case because we hoped to switch entirely to EP-based building. Due to some unsolved issues regarding using EP builds in CI, add the ability to control the installation of non-EP examples. This will be used in the CI to allow removing the hacky INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR assignments in example projects. It is also likely that we will not deprecate the non-EP based building, because it is useful for IDE integration (EP targets are not as developer-friendly to work with in an IDE in regards to rebuilding). Amends 98c89c8cc1c5ceb4bfbb5f5ed6c96ecdbab99afa Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I02264aaa1daa2c80bb9ef3d02b1831b4ca5d2b84 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Rename QT_INTERNAL_CUSTOM_INSTALL_DIRAlexandru Croitor2022-04-042-6/+8
| | | | | | | | | | | | | | | | to QT_INTERNAL_EXAMPLES_INSTALL_PREFIX so it's clear that the variable only affects the location of where examples are installed. And make sure the paths are passed as CMake paths. Amends 1031fa15472bba3f20691cda2305e0821391c5db Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: Ib92c55488b736d980da2bd88255de78e183de824 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow passing -v to ninja when building examples as EPsAlexandru Croitor2022-04-041-0/+7
| | | | | | | | | | | | | | | | | | | | By default when building ExternalProjects, even if the main ninja invocation has -v passed, that won't be passed to the nested ninja calls. When building examples in the CI, we want to see the full command line invocations. Allow passing -v to the nested EP ninja calls by configuring Qt with -DQT_INTERNAL_VERBOSE_EXAMPLES=ON, which we will use in our CI. We don't want to add -v by default because if the main ninja does not have one, the nested calls will still be verbose. Pick-to: 6.2 6.3 Change-Id: Ifd4b312c6eaa7354e8870f4fb0a77fadf0f33ab7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Pass -v to ninja when using ctest --build-and-testAlexandru Croitor2022-04-041-1/+3
| | | | | | | | | | | | | | | | | So we can see the command line invocations of the built cmake auto tests. To achieve that, we create a ninja shell script wrapper, because ctest --build-and-test does not currently allow specifying custom build tool options. Details at https://gitlab.kitware.com/cmake/cmake/-/issues/22443 Pick-to: 6.2 6.3 Change-Id: I7fb3b7f7f802943a7013c859b2cf39842a34e2e4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Make possible to set android SDK/NDK roots from environmentAlexey Edelev2022-04-041-0/+14
| | | | | | | | | Read the ANDROID_<SDK|NDK>_ROOT environment variables in qt toolchain file and use them to chainload the android toolchain file. Pick-to: 6.2 6.3 Change-Id: I1940ffbaa557974fc26005f4d051030f2cc5c7e0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add WASM testrunnerDavid Skoland2022-03-312-0/+5
| | | | | | | | | Add a python script that allows us to run wasm tests in CI, along with the necessary cmake logic to install the script and execute tests accordingly. Change-Id: I93b95c115538c4e27b2b833405acab8162be2a8a Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* configure: Add mold to helpTasuku Suzuki2022-03-311-1/+1
| | | | | | | | Pick-to: 6.2 6.3 Task-number: QTBUG-99270 Change-Id: I08ee2b328a1dba2bf0172e5a03ddb32925401d3b Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix picking of the binary_for_strip project locationAlexandru Croitor2022-03-292-20/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix binary_for_strip project not being found when the following conditions were met: - building a repo other than qtbase - qtbase sources are not available on the machine (usually happens in CI where only the current repo sources are available). The issue was that QT_CMAKE_DIR would always be defined, regardless of which repo was being built and the system would incorrectly assume the location of the project files. The fix is to always pick up the sources from qtbase's source dir if they are available (this time done with an appropriate check), otherwise use the installed files. Note that the behavior of always using the qtbase sources if available is not exactly the best, but it is a more general issue that affects other code too. In the name of consistency, make it so for the binary_for_strip project as well, but add TODOs in code to address the situation in a separate change. Amends 39f657032b5e65bfcb93472201f6607c0388ba37 Pick-to: 6.2 6.3 Fixes: QTBUG-102064 Task-number: QTBUG-88090 Task-number: QTBUG-101653 Change-Id: I0649f945e9ff0ab1f597c51bb5ab389fa665c021 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't hardcode the library directory nameChristophe Giboudeaux2022-03-291-1/+1
| | | | | | | | | | | Using INSTALL_LIBDIR is the only reliable way to get the library install directory. Amends: d1c56073b4cf3346168413e7d931c63355307e9d Pick-to: 6.2 6.3 Change-Id: Ib8c4fb8b4d339c63209393d7fdb3d1c3425b03a4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix handling of the CROSSCOMPILING_EMULATOR propertyJoerg Bornemann2022-03-251-2/+3
| | | | | | | | | CROSSCOMPILING_EMULATOR is a target property, not a test property. Fixes: QTBUG-87864 Pick-to: 6.2 6.3 Change-Id: Icb07e9ed71a6bcbfceb7aa2116bf56eaa0a545c6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix typo in configuration summary messageAlexandru Croitor2022-03-251-1/+1
| | | | | | | | Amends 384dfceb532cada5f4be96430c8c7c866f40c933 Pick-to: 6.2 6.3 Change-Id: Ica36551b64899848ab40e507ddf002af55b7db8c Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Disable SAFE_HEAP_LOG for wasmDavid Skoland2022-03-251-1/+0
| | | | | | | | | | This option completely ruins the output when running test, as it logs every single safe heap operation. I don't think this detailed logging is necessary or reasonable in a normal debug build. Pick-to: 6.3 Change-Id: I4bb740299d631d21453f9b4a8959634801fb3a1e Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* CMake: Generate and use a wrapper script for stripping binariesAlexandru Croitor2022-03-243-0/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MinGW 11.2.0 comes with a strip.exe that strips the ".gnu_debuglink" section in binaries, a section that is needed for the separate debug information feature. binutils version 2.34 mentions the feature for the first time: https://sourceware.org/binutils/docs-2.34/binutils/strip.html#strip To ensure the debuglink section is preserved, generate a shell wrapper that calls the original strip binary with an extra option to keep the required section. To determine if the option is supported, we build a real shared library on which strip will be called with the --keep-section option. If the option is not supported, a wrapper is not generated and the stock strip binary is used. This logic only applies when targeting Linux and MinGW + a shared library Qt. For other targets, the stock strip binary is used. Developers can opt out of this logic by passing -DQT_NO_STRIP_WRAPPER=TRUE when configuring each Qt repo. Pick-to: 6.2 6.3 Fixes: QTBUG-101653 Change-Id: Idd213d48d087d3c9600c853362aebaba348cde33 Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Enable verbose autogen for cmake auto tests and EP examplesAlexandru Croitor2022-03-241-0/+1
| | | | | | | | | | | | | | So we can see the exact moc invocations when debugging issues in the CI. For ExternalProject examples, it is conditional on whether Qt is configured with QT_INTERNAL_VERBOSE_EXAMPLES set to ON, otherwise calling the main ninja without -v will end up cluttering the output with AUTOGEN output. Pick-to: 6.2 6.3 Change-Id: I6468ab0e461b3be283e2428e3515cae4d5986242 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Enable debug verbosity for cmake auto tests and EP examplesAlexandru Croitor2022-03-241-0/+3
| | | | | | | | | | | | | | | | | | | | Since e2a0ddbb69640c94b4ee107260a088d5c1c7e273 , if Qt is configured as a non-developer-build, some of the CMake tests that include QtSetup would have their CMAKE_MESSAGE_LOG_LEVEL set to the reduced NOTICE value. Make sure that tests always have a DEBUG level, so that if they fail in the CI, we have more info on what goes wrong. For ExternalProject examples, it is conditional on whether Qt is configured with QT_INTERNAL_VERBOSE_EXAMPLES set to ON, otherwise calling the main ninja without -v will end up cluttering the output a non default log level. Amends e2a0ddbb69640c94b4ee107260a088d5c1c7e273 Pick-to: 6.2 6.3 Change-Id: Icd3b6e0fcc6c73e4b53b6c4a6d8354c96077a050 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-25 22:55:38 +0000