summaryrefslogtreecommitdiffstats
path: root/cmake/QtPrlHelpers.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Fix generated prl and pri files for MSVCLi Xinwei2021-06-021-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In MSVC static build, if we build Qt with 3rdparty library (e.g. zstd), cmake will add"zstd" (without "-l" prefix) to Qt6Core.prl. Then we use this Qt to build a qmake project, compilation will fail due to missing zstd.obj. Without "-l" prefix, qmake will treat "zstd" as an object file instead of a library. Library names in qt_module.pri and qt_lib_*_private.pri are also missing "-l" prefix. This is because on most compilers, CMAKE_LINK_LIBRARY_FLAG equals "-l". But on MSVC, it is an empty string. So we should pass "-DLINK_LIBRARY_FLAG=-l" for MSVC. Also add "-L/path/to/library" if the library path is not in default linker search directories. This will write un-relocatable paths to prl files only when using 3rdparty libraries to build Qt statically. Usually it's not a problem. In addition, CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is also empty on MSVC. So The third argument of "$<FILTER>" is empty, it is an invalid generator expression. This means no include dir will be written to qt_module.pri and qt_lib_*_private.pri on MSVC. So only use "$<FILTER>" when CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is not empty. Pick-to: 6.1 Change-Id: Ib66f95dc09cf920363a4b9338fb97747dd2f8ab7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make qt_internal_walk_libs available in public projectsAlexandru Croitor2021-05-111-237/+2
| | | | | | | | | | | | | | | | | | Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add ABI suffix to .prl files for AndroidJoerg Bornemann2021-05-031-1/+5
| | | | | | | | | The libraries already contain the ABI suffix, and the .prl files should too. This is a requirement for ABI-stitching of Qt Android builds. Fixes: QTBUG-90023 Change-Id: Ib2a7b3119ace14c8542242fc45f42648840d053a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Check if all required Qt targets are declared when finalizing the moduleAlexey Edelev2021-04-151-0/+3
| | | | | | | | | | | | | | | | | | CMake makes possible to specify a target in the target_link_library call even if the target is not declared yet. This adds flexibility to the target declaration arrangement. For the Qt modules we have to restrict freedom, because of the .prl files generating. If the Qt module depends on another Qt module, the dependecy must be declared before the module finalizing step, otherwise this will cause invalid records in the module .prl file. TODO: The dependency order issue could be solved by using conditional genex's when generating step1 .prl file. But we ask developers to depend on Qt module targets that have been defined before their usage. Fixes: QTBUG-89467 Change-Id: I12ce1000048fd4a2f3334f17720c8df1c680ca20 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix linking order of the resource objectsAlexey Edelev2021-04-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix QMAKE_PRL_LIBS entries on Windows for modules from other reposJoerg Bornemann2021-01-221-1/+1
| | | | | | | | | | | | | | | | | | | | | When building a repository != qtbase, like qtactiveqt, QMAKE_PRL_LIBS contained entries like Qt6Core and Qt6Widgets, meaning the linker line would contain exactly these arguments. When building an activeqt example with qmake, the link then failed with "LNK1181: cannot open input file 'Qt6Widgets.obj'". The correct entry would have been $$[QT_INSTALL_LIBS]/Qt6Widgets.obj. Fix this by determining the full path to the import library in the first step of the prl generation. This enables QtFinishPrlFile.cmake to recognize Qt6Widgets as Qt module and generate the right QMAKE_PRL_LIBS entry. Pick-to: 6.0 Fixes: QTBUG-90520 Change-Id: Id0d9178da0e0dfc3ea4fadbbe8f5900d792ffc84 Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Fix resource object file paths in prl files for prefix buildsAlexandru Croitor2020-11-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Fix value of QMAKE_PRL_TARGET in generated .prl filesJoerg Bornemann2020-11-251-1/+1
| | | | | | | | | | | On DLL platforms, the value of QMAKE_PRL_TARGET should be the import library (foo.lib), not the actual DLL (foo.dll). The genex TARGET_LINKER_FILE_NAME provides exactly that. Fixes: QTBUG-88864 Pick-to: 6.0 Change-Id: I553930bb840007772fe8f4612f95e0e320f54107 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Rename the qt resource properties to be internalAlexandru Croitor2020-11-191-2/+2
| | | | | | | | | 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: Fix resource objects story in static prl filesAlexandru Croitor2020-11-191-25/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CMake build of Qt intends to improve the developer experience in regards to static Qt builds and Qt resource files. Specifically with a CMake build of Qt, Qt developers don't have to manually call Q_INIT_RESOURCE anymore. For details see the following commits e343affd6345ef8db041789a96016c3a84830dc9 e817ac3d68295fc0670ccede4df08bf1c7e627d2 4ab54320817ebbb465af343514d21139a654aed3 The last commit's implementation is incomplete though. To ensure successful linking, each target's prl file should contain not only the resource object files that are assigned to the target, but also all resource object files of the target's dependencies. To achieve that, qt_collect_libs will now recursively collect all resource object files assigned to the QT_RCC_OBJECTS property of each dependency. Note this implementation is still incomplete. We do not export rcc object file information in the CMake Targets files. That means that when configuring qtdeclarative in a non-top-level build, the generated Qml prl file will not contain references to Core's mimetypes resource object file, etc. So with the current change, only the object files that are part of the current CMake configuration build are tracked. Exporting the resource object files locations proves in a format usable for prl files proves to be difficult (due to CMake not supporting exporting genexes in random properties) and will have to be addressed in a separate change. Amends 4ab54320817ebbb465af343514d21139a654aed3 Task-number: QTBUG-88425 Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Refactor parts of qt_internal_walk_libsAlexandru Croitor2020-11-191-9/+55
| | | | | | | | | | | | | | | | | | | | | | | | Refactor the function in preparation of processing rcc object files. Introduce 2 new functions to get and set values in the memoization dictionary used by qt_internal_walk_libs. Modify qt_internal_add_target_aliases to assign the alias names it creates as properties on the target. Extract these aliases when available to assign memoized values not only for the initial library name, but also for its aliases. When recursively calling qt_internal_walk_libs, make sure to provide a unique out_var name based on the outer target name, and not just lib_libs. Otherwise the out_var values would be polluted from previous recursion runs. Make sure to check for -NOTFOUND in if() checks so that we reuse memoized values that are the empty string. Change-Id: I8fd8e2b0ae14d0ba8f502bc5a764d6e01095001a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Remove indirection via Startup target for EntryPointTor Arne Vestbø2020-11-121-3/+3
| | | | | | | | | | | | | 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: Fix generation of prl files for non-qtbase modulesAlexandru Croitor2020-10-291-1/+7
| | | | | | | | | | | | | | | | | | | Previously we determined if a library represented by an absolute path is a Qt module by checking if it's located in the build dir of the current repo. That is not sufficient for non-qtbase prefix builds, where a Qt module might link against both a module in the current build dir and in the prefix dir. Detect such cases, and rewrite the absolute paths to relocatable paths (either framework flags or paths starting with $$[QT_INSTALL_LIBS]. This should fix building examples with qmake that use QtQuick. Fixes: QTBUG-87840 Change-Id: Icaf8f1a7c66292c80662fd0d5771a5a1628a9899 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Introduce Qt6::Startup targetAlexandru Croitor2020-10-121-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | 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 QtBuild.cmake into smaller filesAlexandru Croitor2020-08-141-0/+313
QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-18 00:52:04 +0000