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>
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 f9dcade5e7
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>
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>
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>
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
e343affd63e817ac3d684ab5432081
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 4ab5432081
Task-number: QTBUG-88425
Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
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>
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>
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>
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>
