summaryrefslogtreecommitdiffstats
path: root/src/corelib/Qt6CoreConfigExtras.cmake.in
Commit message (Collapse)AuthorAgeFilesLines
* Move QtInstallPaths.cmake to the Qt6 packageAlexey Edelev2024-03-221-2/+0
| | | | | | | QtInstallPaths needs to be loaded at early stages Change-Id: Ie275ad2a8855b7555b110c35814ebadafe1817c6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove the commented legacy code from Qt6CoreConfigExtras.cmake.inAlexey Edelev2024-02-071-10/+0
| | | | | | Pick-to: 6.7 6.6 6.5 Change-Id: I44243ed239c21382569f0c4abf9a271da42b9a19 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Improve the QT_NAMESPACE definition in Qt6CoreExtrasAlexey Edelev2024-02-071-3/+1
| | | | | | | | | The perivous version generated weird condition, and seems changing the QT_NAMESPACE after qtbase configuration is noop, we may replace the generated condition with the conditional generation. Change-Id: Ifa09dba4db00099a07da2cff5505e6fd0b008289 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* do not override initial AUTOMOC_MACRO_NAMES valueSami Shalayel2023-11-281-1/+2
| | | | | | | | | | | | | The CMake documentation states that the AUTOMOC_MACRO_NAMES property of a target is initially set to CMAKE_AUTOMOC_MACRO_NAMES, so do not override it in qt_enable_autogen_tool. Instead, append the extra macro names not set by the upstream CMake CMAKE_AUTOMOC_MACRO_NAMES variable. Add a test for this. Change-Id: Ib0ef28e7fc9c5f9559150bbe73ffdeac767adc82 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Store info about the debug build in QtDeploySupport.cmakeJoerg Bornemann2023-09-261-0/+1
| | | | | | | | | | | | | | Application deployment must know whether the Qt installation is a debug_and_release build - or more generally, a multi-config build with a debug configuration. Store the following information in QtDeploySupport.cmake that's read at installation time: - whether Qt was built multi-config with a debug configuration - the postfix for debug libraries Task-number: QTBUG-109444 Pick-to: 6.5 6.6 Change-Id: I96a2120ba1a2b03125661cc829498653e37dfb0f Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Avoid resetting CMAKE_AUTOMOC_MACRO_NAMESAmir Masoud Abdol2023-02-281-1/+2
| | | | | | | | | | | | | Instead of overwriting the CMAKE_AUTOMOC_MACRO_NAMES, we try to append our desired moc names to it, and don't get rid of what's there. Thanks for Friedrich W. H. Kossebau for filling a descriptive bug report and offering a solution as well. Pick-to: 6.5 6.4 6.2 Fixes: QTBUG-110497 Change-Id: I582af431151cacfe24085b890ae9dba0a0e53f3f Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Add permission API backend for macOS and iOSTimur Pocheptsov2022-11-031-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When submitting applications to the iOS and macOS AppStore the application goes through static analysis, which will trigger on uses of various privacy protected APIs, unless the application has a corresponding usage description for the permission in the Info.plist file. This applies even if the application never requests the given permission, but just links to a Qt library that has the offending symbols or library dependencies. To ensure that the application does not have to add usage descriptions to their Info.plist for permissions they never plan to use we split up the various permission implementations into small static libraries that register with the Qt plugin mechanism as permission backends. We can then inspect the application's Info.plist at configure time and only add the relevant static permission libraries. Furthermore, since some permissions can be checked without any usage description, we allow the implementation to be split up into two separate translation units. By putting the request in its own translation unit we can selectively include it during linking by telling the linker to look for a special symbol. This is useful for libraries such as Qt Multimedia who would like to check the current permission status, but without needing to request any permission of its own. Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Change-Id: Ic2a43e1a0c45a91df6101020639f473ffd9454cc Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Move install paths from CoreConfigExtras.cmake to a separate fileAlexey Edelev2022-10-251-17/+3
| | | | | | | | | Move install paths from CoreConfigExtras.cmake to a separate file for the easier usage. This specifically can be useful to detect read required paths for android deployment in multi-ABI builds. Change-Id: Iacdf3a8d3ae7615ac6669a067e6f12bdf5043d5a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* wasm: add support for building Qt as shared librariesMorten Sørvig2022-08-301-0/+1
| | | | | | | | | | | | | | | This implements the build system bits required to build Qt as as separate wasm modules a.k.a Emscripten side modules. Enable by configuring with the "-shared" flag. This is the first step towards shared library support and gets us as far as being able to load QtCore and instantiate a QCoreApplication. Task-number: QTBUG-63925 Change-Id: Ib8f07f80fb5b13c8dbba65c7db735dc557b70d0e Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Add the _qt_internal_android_executable_finalizer wrapper functionAlexey Edelev2022-03-021-3/+17
| | | | | | | | | | | | _qt_internal_android_executable_finalizer wraps Android-related function that are needed to created an Android package. The function is added to the INTERFACE_QT_EXECUTABLE_FINALIZERS property in Qt Core so it's called implicitly for user projects. Pick-to: 6.3 Change-Id: I140f53341691dcfdc6ae2ddea520818cf2834eb6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Deduce install prefix of example in qt_internal_add_exampleAlexandru Croitor2022-02-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to get rid of the INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR code in each example project. This was an internal workaround to ensure examples are installed into a relative path somewhere under $qt_prefix/examples and not in $qt_prefix/bin or similar. To achieve that we do two things. First, deduce the install prefix for each example in the implementation of qt_internal_add_example (our add_subdirectory wrapper) and assign it to CMAKE_INSTALL_PREFIX before calling add_subdirectory. We need to make sure to remove the default value of CMAKE_INSTALL_PREFIX in the generated cmake_install.cmake file. Second, we set an internal variable called QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT before the add_subdirectory call, which will be checked whenever find_package(Qt6Core) is called in an example project. If the variable is set, the INSTALL_EXAMPLEDIR var is set to "." in the scope of where Qt6Core is found. This ensures that the hardcoded INSTALL_EXAMPLEDIR values in our example projects are changed to ".". With both changes, our example project install(TARGET DESTINATION) calls will now install to "${CMAKE_INSTALL_PREFIX}/examples/${example_relative_dir}/." Once all repositories are updated to use qt_internal_add_example instead of add_subdirectory, we can get rid of the QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT workaround. For repositories that still don't use qt_internal_add_example, the install prefix rewriting will not happen, but the examples will still be installed to the proper place because they use their own hardcoded INSTALL_EXAMPLEDIR value. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-96232 Task-number: QTBUG-98545 Change-Id: I78c118e10c41b519c570c7d87529afd15aeed900 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Add CMake deployment supportCraig Scott2021-12-081-0/+2
| | | | | | | Task-number: QTBUG-98545 Change-Id: I581c1173cdfc92c09fd2cf0bbe7ec6bc8d52b868 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add _make_aab targetAlexey Edelev2021-11-301-1/+1
| | | | | | | | | | | | | | | | Add target triggering AAB creation. Since the _make_aab target is not added to the ALL set, we may avoid dependency check for it and admit that the target is "always out of date". [ChangeLog][Android][Platform Specific Changes] Add the extra _make_aab targets for each executable target, that can be used to generate android app bundles. Also add aab metatarget to build all _make_aab targets that are created in the project. Pick-to: 6.2 Fixes: QTBUG-96710 Change-Id: I3b0c7fbb5a7dd493ca7a124c4e4b91fd857386bd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Long live Q_GADGET_EXPORT!Marc Mutz2021-11-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | Like Q_NAMESPACE_EXPORT for Q_NAMESPACE, this variant of Q_GADGET allows passing an export macro. This is useful to avoid exporting the whole class just to get the staticMetaObject hidden therein exported. Before anyone asks: No, we don't need Q_OBJECT_EXPORT, because QObject subclasses, being polymorphic, always need to have a class-level export macro (to export their vtable), but while that technique also works for value classes (the Q_GADGET audience), it is not desirable for them, because it makes inline functions exported in Windows debug builds, which is not what we want, because it needlessly restricts what you can to with the inline functions (e.g. remove). [ChangeLog][QtCore] Added the Q_GADGET_EXPORT macro, which is like Q_GADGET, but allows passing an export macro (like Q_NAMESPACE_EXPORT for Q_NAMESPACE). Fixes: QTBUG-55458 Change-Id: I546297de1e8aa45d83381991bcd3fbca61e1eef0 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Add basic android multi-abi support for CMake projectsAlexey Edelev2021-10-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use CMake external project to crosscompile android libraries for mutliple android ABIs at the same time. The idea behind is to use pre-compiled Qt for each android ABI in external projects, compile libraries and then utilize results of compilation in common androiddeployqt call. By default multi-abi build uses the main ABI that qt toolchain file belongs to. The list of the autodetected Qt for Android ABIs is stored in QT_DEFAULT_ANDROID_ABIS cache variable. Users may change the set of the Android ABIs project-wide using QT_ANDROID_ABIS CMake variable or for the specific target by adding the ANDROID_ABIS argument when calling qt6_add_executable. To enable build for the autodetected ABIs user may set the QT_ANDROID_BUILD_ALL_ABIS option to TRUE. By default build procedure is looking for the respective android_<abi> folders to run per-abi build. If user's Qt for Android folder structure is different then one is created by Qt installer, path to the each Qt for Android might be overwritten using QT_PATH_ANDROID_ABI_<abi> CMake variable. Note: This only adds support for the multi-abi build of user's applications. TODO: This commit limits projects to not have in-tree library dependencies. That means that executable targets may have dependencies only from Qt directories or android sysroots. See QTBUG-94714 for details. [ChangeLog][Android][Platform Specific Changes] Added basic support for multi-abi builds of user projects. Task-number: QTBUG-88841 Change-Id: I3239ffe61e6b437e170c8decc5c36a9e774ed0fb Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* CMake: Fix global 'apk' target to actually build all apksAlexandru Croitor2021-06-081-0/+1
| | | | | | | | | | | | | | | | | | | | This means calling 'ninja apk' in a user project with multiple android applications will build all their respective apks. For user projects, make the 'apk' target part of the global 'ALL' target, so that a regular 'ninja' call implies the 'apk' target. We don't do it currently for Qt builds, because certain test executable apks fail to build. Add a QT_NO_GLOBAL_APK_TARGET_PART_OF_ALL variable to allow removing the global apk target from the 'all' target. Pick-to: 6.1 Task-number: QTBUG-94264 Change-Id: I171b9da50eb7d670176704bd26dc1c492118b434 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* wasm: add cmake build supportLorn Potter2021-04-011-0/+4
| | | | | | | | | | | | | | | | A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Ensure Core target has INTERFACE_QT_COORD_TYPE property definedCraig Scott2021-02-021-5/+0
| | | | | | | | | | | | | | | | | | In order for other Qt modules to be able to reliably use this property, it needs to be defined under all supported scenarios. Previously, it would only have been defined for a per-repo build and not for a top level superbuild. The only place it was being set was in the Qt6CoreConfigExtras.cmake file and only when QT_NO_CREATE_TARGETS was false (so it wouldn't be defined for examples even in a per-repo build). It was also noticed that INTERFACE_QT_MAJOR_VERSION was also being handled in Qt6CoreConfigExtras.cmake, but this was not needed. This was already being done as part of a call to qt_autogen_tools_initial_setup() which occurs inside qt_internal_add_module(). Fixes: QTBUG-90617 Change-Id: I589316ffb8138bd2df8a1d49fdd6335d2e2836f1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Remove indirection via Startup target for EntryPointTor Arne Vestbø2020-11-121-2/+0
| | | | | | | | | | | | | The EntryPoint interface target now contains all the logic for what flags and optional static libraries to add when the entrypoint is enabled. The target property QT_NO_ENTRYPOINT can be used to disable the entrypoint. Change-Id: I9b14ff729366cd6307789c969ebd4b2ca19de77d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Set some additional info variables in Qt6CoreConfigExtrasAlexandru Croitor2020-10-121-0/+2
| | | | | | | | | | Add info whether Qt was an infix built, and whether the reduce_exports feature was enabled. These variable were set before in Qt5CoreConfigExtras.cmake. Change-Id: Id077763cfffd5ee6f1a7a28d04cf92dc46390c54 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Introduce Qt6::Startup targetAlexandru Croitor2020-10-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Add an abstraction over Qt::WinMain (aka qtmain.lib) and iOS's runtime linker entry point (_qt_main_wrapper). The Core target will now link against the Startup target on all platforms, instead of just WinMain on Windows. The creation and linkage interface definition of the Startup target is done at find_package(Qt6Core) time via the private call of _qt_internal_setup_startup_target(). This will add automatic linkage of WinMain to executables marked with the WIN32_EXECUTABLE property on Windows. As well as the addition of the '-Wl,-e,_qt_main_wrapper' linker flag when linking iOS executables. Qt users can opt out of this behavior by either setting the QT_NO_LINK_QTMAIN property or variable. This is in line with Qt 5 behavior. Task-number: QTBUG-87060 Change-Id: I7d5e9f1be0e402cf8e67e6f55bfd285f9e6b04f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Split out some Android functions into a public API fileAlexandru Croitor2020-08-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To fix CMake Qt For Android projects to configure, we need to move some functions from a private CMake API file only, to a public one. Add Qt6AndroidMacros.cmake which will be loaded by Qt6Core package. We'll have to decide how we proceed with Qt5AndroidSupport.cmake, because that file automatically runs code when included in Qt5, and we usually don't want to do it. We'll also have to decide how to handle the define_property() calls that are still left in the private QtPlatformAndroid.cmake file. With this fix, Qt example CMake projects that use add_qt_gui_executable should now be buildable. An APK can be created with 'ninja apk'. Unfortunately Qt Creator 4.13 does not currently seem to support opening and building CMake Qt For Android projects properly. While the build succeeds after fiddling with the Kit settings, the APK deploy step fails to run (at least on my machine). So the simplest way to run the built APK is to open the android-build dir with Android Studio and launch the example application from there. Task-number: QTBUG-85399 Change-Id: I77f246331de7a6e9e6d4ba7d973730190138f136 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Expose public info about whether Qt is a shared lib buildAlexandru Croitor2020-08-121-0/+1
| | | | | | | | | | We expose it in the private QtBuildInternals package, but we need it also as public information for consumption in qt_import_qml_plugins() to decide whether it should do anything. Change-Id: If135ae596b4edaf8e2c458f6a2518b968c6d01c4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Get tests/auto/cmake tests workingAlexandru Croitor2020-07-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tests/auto/cmake project can be configured separately as a standalone project with qt-cmake, or as part of the overall qtbase standalone tests. To do that a bunch of things were done - Ported all Qt5 strings to Qt6 - Replaced in all projects the use of add_definitions and include_directories with a target based approach, except for 2 tests where we check that the old-style approach works, otherwise the tests would file - Removed some (possibly unneeded) EGL / OpenGL tests - Fixed some C++ code - Added setup code to tests/auto/cmake/CMakeLists.txt to figure out which modules are available and should be tested - Fixed Qt6CTestMacros.cmake to be loaded by Qt6Core - Removed the CMake tests to not be run in qmake builds of Qt because they would fail anyway - Enabled the CMake tests to be part of standalone tests - Disabled auto-passing of the C and CXX compiler cache vars when cross-compiling so that the tests can somewhat pass on boot2qt. This is the issue we encountered in e2b2cd9397c76e91ac1ebe493bcac7696767c02e - Ultimately disabled tests for boot2qt, because the -rpath-link flag is not generated by CMake for some reason. - Added code to setup the environment when running an executable that was built as part of the test, so that the proper Qt libraries are found. This handles both the standalone tests case and separate project case. The remaining unported tests are test_import_plugins which requires quite a bit of work to get some modules and plugins built that were done as part of the qmake .pro files, test_plugins that checks some Network plugins which I'm not sure about, and test_add_big_resource which doesn't work with namespaced builds and there's no good way of detecting those at the moment either. Change-Id: Ic8809c72817d1db81af6c6014c11df6473ad8c75 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Make the path variables in Qt6CoreConfigExtras.cmake relativeJoerg Bornemann2020-06-281-13/+13
| | | | | | | | | | | | | To be consistent with the Qt6HostInfo package, we're providing paths without prefix in the variables like QT6_INSTALL_BINDIR. The full path can be easily obtained by combining the relative path with the QT6_INSTALL_PREFIX variable. Also, the value of QT6_INSTALL_SYSCONFDIR was wrong. It usually is located outside of the prefix. Change-Id: I0035633a8c1c865d86d5ffc8b36565ceb2e7ea25 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Port the reduce-relocations featureJoerg Bornemann2020-02-251-12/+0
| | | | | | | | | | As reduce-relocations implies bsymbolic_functions, we also add the -Bsymbolic-functions linker flag. Also, handle the .dynlist files that are passed to the linker by bsymbolic_functions.prf in the qmake build. Change-Id: I535c33fba888596d2f8975b16864bbe9f0a7caa4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add Qt 5 backward compatible CMake APIAlexandru Croitor2020-01-271-0/+3
| | | | | | | | | | | Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Merge remote-tracking branch 'origin/dev' into wip/cmakeLeander Beernaert2019-11-191-0/+2
| | | | Change-Id: Ifecc2d9db396d783124df8567553ba5f846f30bb
* Fix declarative testsAlexandru Croitor2019-10-251-1/+0
| | | | | | | | | | | | | | | | | | | e1fd6074935cd0be0df14d89eb0244fcbd1677cf in qtbase removed the qml1 imports enum from qlibraryinfo.cpp, qconfig.cpp, etc. With the recent merge from dev, this was not adjusted in qt_generate_qconfig_cpp, and thus we generated one too many strings in qconfig.cpp, which resulted in QLibraryInfo::location(QLibraryInfo::Qml2ImportsPath) returning "imports" instead of "qml" subfolder, thus causing all qml modules not being found. Fix this by removing the extra qconfig.cpp entry, and all other references to the location. Change-Id: I128f667281138e2e0ef0fe1ced4af0405c532fef Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Change QT_COORD_TYPE variable which was badly translated from qmakeJean-Michaël Celerier2019-09-241-1/+1
| | | | | | | | | Note that from a quick grep, nothing sets QT_COORD_TYPE in the CMake buildsystem yet, and nothing uses it either. Change-Id: I91241089ff08f6b93d1d0b00e135063cfe516dfc Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge remote-tracking branch 'origin/wip/qt6' into wip/cmakeAlexandru Croitor2019-06-141-0/+52
This changes many different CMake places to mention Qt6 instead of Qt5. Note that some old qt5 cmake config files in corelib are probably not needed anymore, but I still renamed and kept them for now. Change-Id: Ie69e81540386a5af153f76c0242e18d48211bec4
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-14 12:25:50 +0000