summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Use the PRODUCT_NAME for the iOS display name like qmakeAlexandru Croitor2022-05-201-0/+7
| | | | | | | | | | | | | | | | | | | This ensures that the Xcode 'Display name' input under ${target} -> General -> Identity -> Display name is not empty. Because adding ${PRODUCT_NAME} directly in the Info.plist.in template will cause CMake to evaluate it as variable expansion, work around the issue by putting the dollar sign into a separate cache variable that after evaluation will result in ${PRODUCT_NAME} being in the file verbatim, so that Xcode evaluate it at build time. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Task-number: QTBUG-95838 Change-Id: I2d1090cc8e84b32442f7daca2d4ce5e3ad413c68 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix issue with linking against static library on iOSAlexandru Croitor2022-05-201-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently our iOS CMake toolchain file sets the global XCODE_EMIT_EFFECTIVE_PLATFORM_NAME property to OFF, to work around a CMake issue regarding usage of object libraries in conjunction with Xcode. The error was The OBJECT library type may not be used for IMPORTED libraries under Xcode with multiple architectures $(CURRENT_ARCH) While this got rid of the error, it introduced a regression where linking an executable against a static library in the same project failed due to the library not being placed in a directory where Xcode expects it to be. clang: error: no such file or directory: '~/build-untitled4-Qt_6_0_2_for_iOS/Debug/libuntitled4.a' The actual library is created in Debug-iphoneos/libuntitled4.a Note the -iphoneos suffix, which is related to the EFFECTIVE_PLATFORM_NAME. This could be further worked around by either explicitly setting the library ARCHIVE_OUTPUT_DIRECTORY property in the project, or flipping the value of the XCODE_EMIT_EFFECTIVE_PLATFORM_NAME to ON at the end of the project. Both workarounds are not project-friendly. In the mean time CMake got a fix for the original error at https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5771 which got released with CMake 3.20.0. That was unfortunately not sufficient to remove our initial workaround, because removing it would trigger a different error at generation time CMake Error: Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Quick_resources_1> The evaluation of the TARGET_OBJECTS generator expression is only suitable for consumption by CMake (limited under Xcode with multiple architectures). It is not suitable for writing out elsewhere. Fortunately, another fix landed in CMake 3.21.0 to address that https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6161 Because static builds (iOS) require CMake 3.21, with both of these fixes we can now remove our workaround. Even projects that set ARCHIVE_OUTPUT_DIRECTORY or flip XCODE_EMIT_EFFECTIVE_PLATFORM_NAME to ON still continue to work fine. This also fixes installation of libraries, which also took into account the effective platform name and thus caused a mismatch between the expected output dir and the real one. This reverts 1e1805ed36a932dcb085a1ad3308782a136d477c Pick-to: 6.2 6.3 Fixes: QTBUG-93268 Fixes: QTBUG-95381 Task-number: QTBUG-87198 Change-Id: Ifcaf0f89e4328ae9859c596882ce32401fa491c3 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Automatically use Xcode generator in qt-cmake + iOSAlexandru Croitor2022-05-201-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When calling qt-cmake on the command line, we don't usually force usage of a particular CMake generator and defer to the user's choice or CMake's default for the host OS. In the case of iOS, the generator that makes the most sense to use is Xcode. One could also use Ninja / Unix Makefiles if the project is only building static libraries, but for shared libraries and executables the project likely needs the code signing provided by xcodebuild. When targeting iOS, use a different qt-cmake file template. The iOS-specific shell script will set the CMAKE_GENERATOR environment variable to 'Xcode'. If no -G or -D CMAKE_GENERATOR is provided on the command line then the project will use the Xcode generator. Otherwise the generator given on the command line takes precedence. The CMAKE_GENERATOR environment variable from the parent process is completely ignored. The logic is only done for iOS, to reduce the likeliness of breaking the qt-cmake script for other platforms. Note that Qt Creator does not use qt-cmake, but rather calls cmake directly with additional options like the toolchain file, architecture, sysroot, etc. [ChangeLog][iOS][CMake] qt-cmake now defaults to using the Xcode generator when targeting iOS projects. Pick-to: 6.2 6.3 Fixes: QTBUG-100834 Change-Id: I39b3dce47cc9ee2f98678631e4bd035c59c65294 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: set correct COMPILE_PDB_NAME for static librariesLi Xinwei2022-05-204-12/+19
| | | | | | | | | | | | | | | Output names of static libraries might be different from target names. For example, the library name of Qt6::DeviceDiscoverySupportPrivate is "Qt6DeviceDiscoverySupport.lib", and the library name of Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib". This commit make pdb files names consistent with the library names. And make sure we have set correct OUTPUT_NAME property before calling qt_set_common_target_properties()/qt_internal_set_compile_pdb_names(). Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Add option to not include native libraries in APKTinja Paavoseppä2022-05-201-0/+18
| | | | | | | | | | | | | | | | | Sometimes it is not desirable to include the libraries in the APK, e.g. system and vendor apps could prefer having one set of libraries installed on the device. If unbundled deployment is specified, native libraries will not be included in the APK. With unbundled deployment, optional arguments can be passed to set the path to load the libraries on the device. [ChangeLog][Android][Deployment Changes] Adds option for Unbundled deployment, where native libraries are not packaged in the APK. Task-number: QAA-771 Change-Id: Ica51ef83a24dad58c7586bf610a58abe21fc1100 Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Avoid using add_custom_command with PRE_LINK for version scriptAlexey Edelev2022-05-191-6/+19
| | | | | | | | | | | add_custom_command with PRE_LINK doesn't work correctly with Multi-Config builds. The better solution is to introduce a custom target that generates the final version script and link the target to the library target as the dependency. Change-Id: Ib7420af752a6a46f29f411f9f0dc8557410b4f22 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-24 04:54:48 +0000