summaryrefslogtreecommitdiffstats
path: root/src/corelib/Qt6CoreMacros.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Fix linking order of the resource objectsAlexey Edelev2021-04-081-3/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | The generated object resource library depends on the Qt::Core library because uses the functions defined in qresource.cpp. Dummy linking of the Qt::Core to an object library has an effect only when the object library is linked directly to the executable as a target. If we link the object library as INTERFACE library we miss out all the objects that need to be linked to the executable. This behavior is explained here: https://bit.ly/3sFWKvI Thus, the only option to link the object library objects to the endpoint executable is to use TARGET_OBJECTS property in genex, as it's already done. But that means we are losing all profits that target actually has, especially linking the object library dependencies. The combination of both of the above methods does the job. The only thing that looks fragile so far is order. Currently, the order we use in the target_link_library call applies to the linker command line. This means the object library objects must always appear before the object library target. Change-Id: If1f0e35e0445d5e96a1f2249ab44114cd36630e9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Choose better defaults for qt_add_plugin STATIC/SHAREDAlexandru Croitor2021-04-071-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a recent behavior change where the public CMake API qt_add_plugin API took into account the value of BUILD_SHARED_LIBS to decide whether the plugin should be a static or shared library. Instead, use the following new behavior - If no explicit option STATIC / SHARED option is passed, default to whatever flavor Qt was built as. Aka if Qt was configured with -shared, qt_add_plugin defaults to creating shared plugins. If it's a -static Qt, create static plugins. - If an explicit STATIC / SHARED option is set, override the default computed value with the given value. As a result BUILD_SHARED_LIBS does not affect Qt plugins anymore. This is more in line with Qt expectations. Add SHARED as a new valid option to pass to qt_add_plugin (it wasn't before). Add tests to check for the above behavior. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Pick-to: 6.1 Fixes: QTBUG-92361 Task-number: QTBUG-88763 Change-Id: Iae806024ddd5cf10cfe58ddbcebd2818084b0bd7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* wasm: add cmake build supportLorn Potter2021-04-011-0/+3
| | | | | | | | | | | | | | | | 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>
* Add missing compile definitions to the resource object libraryAlexey Edelev2021-03-301-0/+3
| | | | | | | | | The resource object library must be compiled with the definitions specified in Qt::Core. Missing the required definitions causes linker problems when QT_NAMESPACE is defined. Change-Id: If0ca20604e251822279e0d4906c47b94d3b4ceb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Refactor qt_internal_add_plugin() and qt6_add_plugin()Craig Scott2021-03-291-20/+79
| | | | | | | | | | | | | | | | | | | | | | Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* qt6_finalize_executable(): Enable finalizers to be set per-targetCraig Scott2021-02-241-0/+41
| | | | | | | | | | | | | | | | | | | | | Some plugins need to append additional processing to targets that use them. This is most commonly needed for static builds to identify additional plugins that need to be linked, but which cannot be determined automatically by CMake as part of its transitive dependency handling. Check for finalizers on directly linked targets as a way to help automate common scenarios. Because we need to lookup dependency targets and these may have visibility limited to the depender target's scope, we now formally document that finalizers should be called from the same scope as the one in which the target was created. This was loosely expected before, but is now made explicit. Task-number: QTBUG-90819 Task-number: QTBUG-86669 Pick-to: 6.1 Change-Id: I065a3f3a4ab6eeff6a98a655835427949e2fe0f1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Revert "Fix static build with tests"Joerg Bornemann2021-02-071-3/+2
| | | | | | | | | | | | | | | | | | | This reverts commit 74f549b4026710b484f17cd99dbafb074854bd11. Reason for revert: This breaks transitive dependencies. The object file we're adding with target_sources will not be propagated transitively. For example, qmltestrunner depends on QuickTest, and QuickTest depends on Quick. The 'qrc_scenegraph.cpp.o' object file will not be propagated to qmltestrunner if added with target_source(Quick INTERFACE ...). Fixes: QTBUG-90933 Pick-to: 6.0 Change-Id: I11269537ae75de14189f8b5f59094b467e2eee24 Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
* Fix static build with testsJoerg Bornemann2021-02-031-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | A static build of Qt with QT_BUILD_TESTS=ON would fail with errors like this: FAILED: tests/auto/corelib/io/qprocess/testProcessEcho2/testProcessEcho2 undefined reference to `qRegisterResourceData(...)' We create object libraries for resources. In this case, for the mimetypes of QtCore. For static builds we added the object files to INTERFACE_LINK_LIBRARIES of the Qt module the resource belongs to: target_link_libraries(Core INTERFACE "$<TARGET_OBJECTS:$<TARGET_NAME:${resource_target}>>") That is, however, a problem for projects that link only against QtCore, like testProcessEcho2 above. On the linker command line Qt6Core.a is before qrc_mimetypes.cpp.o and that doesn't work, because the latter needs symbols of the former. To have the resource object files before any other libraries on the linker's command line, we now treat them as source files. Pick-to: 6.0 Fixes: QTBUG-90582 Change-Id: Ia2786beb5f7c2eba194e8f00ae8785572df1cf6e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix qt_add_big_resources with namespace buildsAlexey Edelev2021-01-191-0/+1
| | | | | | | | | | | | Add INTERFACE_COMPILE_DEFINITIONS of Qt6::Core to generated rcc object libraries. This propagates QT_NAMESPACE definition to the object library. Fixes: QTBUG-85620 Change-Id: I252d1aaee7b19a49bc321fdd271a5d85a34bf67f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Don't rely on versionless commands or targets existingCraig Scott2020-12-211-3/+3
| | | | | | | | | | Commands like qt6_finalize_executable() should not rely on versionless commands or targets being available, since they can be disabled by a build option. Pick-to: 6.0 Change-Id: I6a9ab6a9b6a6b731590e5b8c43f73b518ed38e81 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Support deferred finalization for qt6_add_executable()Craig Scott2020-12-101-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some parts of qt6_add_executable() need to take into account certain target properties, but the target is created within the function. The caller doesn't get the opportunity to modify those properties before they are used. This change provides a way to defer those property-using steps until either the project explicitly calls a function to finalize the target or the end of the current directory scope is reached. Automatic deferral to end of scope is only supported for CMake 3.19+. With CMake 3.18 or earlier, deferring the finalization step has to be explicitly requested with the new MANUAL_FINALIZATION keyword. The caller is then responsible for also calling qt6_finalize_executable() later. When the keyword is given, automatic finalization is disabled even when using CMake 3.19+. Note that while this could be implemented without CMake 3.19 features, other work relating to qt6_import_qml_plugins() will require it so we may as well use this method now. Fixes: QTBUG-88840 Task-number: QTBUG-86669 Pick-to: 6.0 Change-Id: Ic3854672ba18cff5af2ffd7f63596aa3ac492f33 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Disable static plugin imports for non-executable targetsAlexandru Croitor2020-12-081-1/+8
| | | | | | | | | | | | | | There is no point in generating cpp files containing Q_IMPORT_PLUGIN() macro calls for non-executable targets like modules, plugins and object libraries in a static Qt build. It causes unnecessary compiling of 10+ files for each of those targets. In a static Qt build, plugin imports should only be done for executables, tools and applications. Pick-to: 6.0 Change-Id: Ied90ef2f6d77a61a093d393cfdf94c400284c4f0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Improve long paths handling for static buildsAlexey Edelev2020-12-031-1/+8
| | | | | | | | | | | | Use number-based naming of object libraries produced for generated resources. This reduces path length of subdirectories for object library targets. Amends 08eb485a006dc2baca42eb280ae60e9f0fc00dff Pick-to: 6.0 Change-Id: I1a449290e8a9b969601a1cc1abc6fdcfc0cd9454 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow WIN32 and MACOSX_BUNDLE arguments for qt6_add_executableCristian Adam2020-12-011-0/+1
| | | | | | | | | | | | | | | qt6_add_executable will forward all arguments to add_executable, which works fine on Windows and macOS in regards of WIN32 and MACOSX_BUNDLE arguments. On Android however add_library is being used, and those arguments need to be removed otherwise they will be consided as source files. Pick-to: 6.0 Fixes: QTBUG-88926 Change-Id: Id22fdf91d58d9053eaad2d3c080ea72060d928c0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix resource object file paths in prl files for prefix buildsAlexandru Croitor2020-11-301-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, the prl files always assumed that resource object files are installed into $qt_prefix/lib when doing a prefix build. That was true for qt_internal_add_resource calls, but not for qt6_add_qml_module and qt6_target_qml_files. Change qt_internal_record_rcc_object_files to take a new required INSTALL_LOCATION argument. The argument takes a path relative to CMAKE_INSTALL_PREFIX. Modify __qt_propagate_generated_resource to save the relative path of the generated resource source file, which will be used in the computation of the final resource object file location. This is needed because the Qml resource functions place the source files in a different directory layout, e.g. .rcc vs .qmlcache Modify qt_generate_prl_file to prepend $$[QT_INSTALL_PREFIX]/ instead of $$[QT_INSTALL_LIBS]/ for the resource install paths. A follow up patch is done in qtdeclarative to pass the new INSTALL_LOCATION argument from the Qml CMake functions. Amends f9dcade5e795a631b9a2d93c855aa8198d58e24e Task-number: QTBUG-87702 Task-number: QTBUG-88425 Change-Id: Id17bb517b4cb5d00911bfd10a728ba4e0d44871b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 54d0ca93bca78f8fd31b6761f078e7a96283f183) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Change generated resources namingAlexey Edelev2020-11-241-1/+1
| | | | | | | | | | Align generated resources .qrc file naming to qmake naming. Update tests. Fixes: QTBUG-88581 Pick-to: 6.0 Change-Id: Id8a2f91f23c257e5b8bd371748c2151ec54a6418 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix resource_name variable name in __qt_propagate_generated_resourceAlexey Edelev2020-11-201-2/+2
| | | | | | | | | __qt_propagate_generated_resource used resourceName variable from parent scope instead of one passed to function. Pick-to: 6.0.0 6.0 Change-Id: I18ce8a9f9c01bcfdbab532def55af4e2780d7753 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Rename the qt resource properties to be internalAlexandru Croitor2020-11-191-1/+1
| | | | | | | | | Use lowercase underscored property names. This ensures they will continue to work even for INTERFACE libraries if it ever comes to that. Change-Id: I5281070f25c1eb9f591c79af8b7fa6169c7c0fb7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Add support for -binary option for generated resourcesAlexey Edelev2020-11-121-20/+48
| | | | | | | | | | | | | | | | | Add handling of -binary flag in qt6_add_resources for generated resource file variant. If -binary argument is provided in OPTIONS section of qt6_add_resources function, it will be passed to rcc as argument. File path to output .rcc could be additionally specified by DESTINATION argument. Extra target generated_<resource_filename> will be added to project's 'all' set. Implement tests for new functionality. Fixes: QTBUG-87644 Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Remove indirection via Startup target for EntryPointTor Arne Vestbø2020-11-121-99/+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: Potentially use INSTALL_LIBDIR in qt6_extract_metatypesAlexandru Croitor2020-11-111-2/+7
| | | | | | | | | The INSTALL_LIBDIR value is only set when doing a Qt build. Use it when available, otherwise default to a more 'hardcoded' value. Change-Id: I96b7b8094c699de59ffaff00cd677d8322c474c3 Reviewed-by: Christophe Giboudeaux <christophe@krop.fr> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Fix genex syntax error for iOS entrypointTor Arne Vestbø2020-11-101-1/+1
| | | | | Change-Id: I09f8870b937b7effd547071530636c314d242a16 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Move iOS entrypoint logic to entrypoint libraryTor Arne Vestbø2020-11-101-2/+1
| | | | | Change-Id: Ie0fc8368953a59d06a31847ed417bc3c35f29b90 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix missing resources in Windows debug DLLs/EXEsJoerg Bornemann2020-11-101-6/+8
| | | | | | | | | | | | | | | | | When configuring a Windows build with NMC and "CMAKE_CONFIGURATION_TYPES=Release;Debug", then with CMake 3.18.4 only the targets of the main configuration would get the version resource compiled in. With 3.19.0 RC 2 the problem cannot be observed. Work-around the issue by revisiting our work-around of another CMake issue: use just one object library per target to embed win32 resources. This works with both tested CMake versions and seems cleaner anyways. Fixes: QTBUG-88267 Change-Id: I20f596ab669ae716c330d7aa60aa717b9e3e4aa7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Expose resource source files to IDEsAlexey Edelev2020-11-081-0/+17
| | | | | | | | | Add fake targets for .qml/.js and other files added using qt6_add_resources Task-number: QTBUG-87642 Change-Id: I690b223711afe96ea7fdb4cf11b8e3317ed9bbe6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix unnecessary rebuilding upon reconfigurationAlexandru Croitor2020-10-301-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The following MR in upstream CMake makes sure that the autogen targets depend on the CMakeLists.txt file associated with the autogen target, as well as any files it includes. https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5166 When doing a no-op reconfiguration in the build dir (call 'cmake .') we used file(WRITE) to prepare the contents of a file to be used with configure_file() for creation of a .qrc resource file. Because this file was always rewritten on reconfiguration, its timestamp was newer than then autogen target's timestamp which caused the autogen targets to-be rerun, as well as some compilation and relinking. To avoid this, instead of using file(WRITE) ship a template file next to the Qt6CoreMacros.cmake file, and use it as a template for the qrc configure_file() call. This ensures that a reconfiguration doesn't necessarily rebuild things it shouldn't rebuild. Amends 113f1ad324202ea2b861a3dbdec2ee7ef716c283 Task-number: QTBUG-88004 Change-Id: Icd95b28ca3642434cf21e5c49dcbd1ec65d76252 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Make qt_add_executable more minimalisticAlexandru Croitor2020-10-271-8/+1
| | | | | | | | | | | | | | | | | | | | As per the public API review, we want qt_add_executable to be a minimal shim around CMake's add_executable with as little Qt specific behavior as it makes sense. This means: - not setting the WIN32 and MACOSX_BUNDLE - not linking against Gui, only Core - not generating a windows RC file Users should handle those particularities themselves, ensuring that qt_add_executable can be used by a bigger audience. Fixes: QTBUG-87664 Task-number: QTBUG-86827 Change-Id: Ib424dd95266352eb035a344ca03b6b81e47bd9e8 Reviewed-by: David Faure <david.faure@kdab.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Use versionfull functions within our public APIAlexandru Croitor2020-10-271-2/+2
| | | | | | | | | This ensures that the public functions still work even if QT_NO_CREATE_VERSIONLESS_FUNCTIONS is true. Task-number: QTBUG-86827 Change-Id: I5654eb17ffe47a1b8e9d397e0477f5b82a762ae1 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Provide add_qt_gui_executable for a short timeAlexandru Croitor2020-10-191-0/+5
| | | | | | | | | | | | | Until all repos are updated to use qt_add_executable instead. This is a minimal addition, instead of the previous QT_NO_INTERNAL_COMPATIBILITY_FUNCTIONS approach which did not work in all cases. Amends c3fee0d984e59cee3ab6d069011015dd850be98f Task-number: QTBUG-87661 Change-Id: I03bbb1451de8e54be4e075f878ed104c287aa93f Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* CMake: Rename add_qt_gui_executable to qt_add_executableAlexandru Croitor2020-10-191-1/+8
| | | | | | | | | | | | | | | | | | Also adjust pro2cmake to use the new qt_add_executable name instead of add_qt_gui_executable. No compatibility functions provided this time, so we'll need to follow through all repos and regenerate all examples. Two reasons for not providing compaitibility functions: 1) We don't intend add_qt_gui_executable to be public API 2) A previous case with qtquickcontrols2 and qttools pointed out that making top-level builds work with cross-compatibility API is not simple. So just go ahead and regenerate everything. Task-number: QTBUG-87661 Change-Id: I2f228827b786ae03bf7e1bf3908ea02a8794ed52 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Generate qrc files at configure time and make them traceableCristian Adam2020-10-171-1/+4
| | | | | | | | | | | Having the qrc files at configure time allows qmlimportscanner to scan them when invoked with -qrcFiles argument. The traceability part is done via _qt_generated_qrc_files property. Task-number: QTBUG-85994 Change-Id: I75c252a987cd1c1f49ba73ec9d100edc73c23486 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Generalize the winmain/qtmain entry-point libraryTor Arne Vestbø2020-10-171-2/+2
| | | | | | | | | | The use-case is relevant for other platforms as well. Now that Qt has a module system we can also replace a lot of the hand crafted logic for linking with simpler constructs. Change-Id: Ib6853aaf81bfea79c31f2de741d65b4b56f23ef6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Rename some public API functionsAlexandru Croitor2020-10-161-29/+28
| | | | | | | | | | | | | | | | | | | Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix qt_add_plugin to be a proper public API functionAlexandru Croitor2020-10-161-6/+1
| | | | | | | | | | | | | | | | | | | | When configuring an example like widgets/tools/plugandpaint/plugins/basictools outside of a Qt build, the configuration fails because it tries to call the internal function instead of the public one. This was needed some time ago to facilitate moving from qt_add_plugin to qt_internal_add_plugin, so some compatibility code was added. But we've now migrated to qt_internal_add_plugin across most repos, so we should remove the compatibility code to allow examples to configure successfully. Amends 6fbeef4c6b2323fc4b7856520c0f38f8139c9c54 Fixes: QTBUG-86858 Change-Id: Ib15f50351a8742c44d7a8be84be4e576cb48bddb Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Rename qt6_quick_compiler_process_resources to be internalAlexandru Croitor2020-10-121-1/+1
| | | | | | Task-number: QTBUG-86827 Change-Id: I9d97b53a8c85e0c488be312c8894a1d73397eb13 Reviewed-by: Simon Hausmann <hausmann@gmail.com>
* CMake: Introduce Qt6::Startup targetAlexandru Croitor2020-10-121-0/+100
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix "Runing" typo in CMake configDavid Skoland2020-10-121-1/+1
| | | | | Change-Id: I77f2970d70ab221e5d7d5c5d389041ed1b6c49f5 Reviewed-by: Daniel Smith <Daniel.Smith@qt.io>
* CMake: Clean up the public API a bitAlexandru Croitor2020-10-011-4/+16
| | | | | | | | | | Add some missing versionless functions. Rename some functions that are not meant to be public API, and their usages. Task-number: QTBUG-86827 Change-Id: Ifb66c04cd7598d83fe80c01a92ab2d269ebaf396 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* qt_add_plugin: Get CLASS_NAME as a one value parameter, add TYPEMårten Nordheim2020-09-251-2/+1
| | | | | | | | | | | | I accidentally made the CLASS_NAME a multi-value parameter when adding it. Add a TYPE argument, which was likely intended to be there since it is already used in an android branch. Change-Id: Ic44dbbaeebc6863a984a7c2effbc00c3c2796b0b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't use std=gnu++11 when building Qt internal targetsAlexandru Croitor2020-08-051-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic is a bit involved in qmake. The Qt internal qt_common.prf adds CONFIG += strict_c++ which applies to qt modules, qt plugins, qml plugins, qt helper libs, winmain and qt_apps, qt_tools, but NOT tests (which is important because the tests on Windows MinGW fail to build without the GNU extensions). Then default_post.prf checks for the strict_c++ value and either uses the strict or non-strict C++ standard flags. default_post.prf is loaded for all qmake projects, not just the Qt internal ones. Now CMake doesn't provide a transitive based option to disable C++ GNU extensions with a mechanism similar to target_compile_features. It only provides the CXX_EXTENSIONS property and it's associated CMAKE_CXX_EXTENSIONS variable. We can't set the variable at a directory scope, because that is too coarse grained. So we rely on setting the property via a function in every relevant qt_add_<target> function. Now the naming of the function is weird. We name the function as qt_internal_<...>, because it's not meant to be used by Qt users. We prepend an underscore to the name because we need to place it in Qt6CoreMacros, so that the function can be called by qt_add_qml_module which IS a public function. That's because in Qt5 load(qml_plugin) was private API, but in Qt 6 + CMake we decided to make qt_add_qml_module() as public API. Change-Id: Id014626b087d590e25cb46843f93d0c67fc36e44 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Introduce qt_internal_add_appAlexandru Croitor2020-07-311-1/+1
| | | | | | | | | | | | | | | This new function is meant to be used where load(qt_app) is used. It delegates functionality to qt_add_executable, while handling some additional behavior via a finalization function (mostly handling of macOS Info.plist files and icons, as well as Windows icons and resource files) It uses a new PlatformAppInternal interface target. Task-number: QTBUG-85757 Change-Id: I1a2d5851b137fcd4a6323e0e06fb154f91619800 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix dependency in qt_add_big_resourcesKai Koehne2020-07-081-1/+1
| | | | | | | | | | | | Ensure that the second rcc pass is executed whenever the object file changes. Patch provided by Hongpeng Liu <lhpzwd@163.com> Fixes: QTBUG-85186 Pick-to: 5.15 Change-Id: I6e52ec15048ab286efd85500ca535b2b8b01c270 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Apply symbol visibility settings to Objective-C/C++ sourcesTor Arne Vestbø2020-06-251-0/+2
| | | | | | | | | | | | | | | 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: Write object libs of Qt resources to .prl filesJoerg Bornemann2020-06-161-0/+1
| | | | | | | | | | | | | | | 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: Check CMAKE_CONFIGURATION_TYPES when doing automoc extractionAlexandru Croitor2020-05-291-1/+1
| | | | | | | | | | Otherwise when configuring a standalone example without specifying a CMAKE_BUILD_TYPE (so it's empty), building fails because qt6_generate_meta_types_json_file thinks it's being called with a multi-config generator. Change-Id: I360c7dbb19522155d8e72f98836fb663916715a0 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Use default location for installing metatypes json filesAlexandru Croitor2020-05-291-47/+66
| | | | | | | | | | | | | | | | | | | | | Previously configuring a standalone example that had no explicit INSTALL_DIR option for qt6_generate_meta_types_json_file would fail. When no explicit location is specified to qt6_generate_meta_types_json_file via INSTALL_DIR option, default to installing into a lib/metatypes location relative to the install prefix. This is required for supporting calling qt6_generate_meta_types_json_file when building standalone applications or libraries (not part of the Qt build). Make sure not to install the metatypes.json file for executables. Install it only for libraries (aka modules). Task-number: QTBUG-84403 Change-Id: Ie0dd75fca0cde71ccb4eb48030871e72d31d1725 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake Build: Do not set "lib" prefix for modules (plugins)Cristian Adam2020-05-291-0/+4
| | | | | | | CMake sets "lib" as default prefix for Windows-GNU platforms. Change-Id: I49e3123c385610307c84c584a21f5f3827a6fafd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Enable default usage of utf8 sources for Qt consumersAlexandru Croitor2020-05-151-0/+7
| | | | | | | | | | And enable the same default when building Qt itself (it's implicit). Allow opting out on a target-by-target basis, by using the public qt_disable_utf8_sources() API call. Change-Id: Ifc19a744d57b96b1c74a6926a0c6628c2a820464 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Use correct file typeYuhang Zhao2020-05-121-1/+6
| | | | | Change-Id: Ie32a32bd1cc3e5885a6699e8ea2281982527e50e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* qmake: Remove the DISCARDABLE flag for icon resourcesYuhang Zhao2020-05-111-1/+1
| | | | | | | | | | According to [1] the DISCARDABLE attribute is for 16-bit Windows, and it is ignored. We can drop it. [1] https://docs.microsoft.com/en-us/windows/win32/menurc/common-resource-attributes Change-Id: I70e5b0441a9d20f6c76c3d7a84947f8bce5c8fbd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>