The qt6_add_big_resources command was dysfunctional whenever AUTOMOC was
enabled for a target.
We passed multiple object files with the --temp argument of the second
pass of rcc. We must pass exactly one. The spurious object file was the
one that's created by AUTOMOC. Turn off all of AUTOGEN for the C++
source file that's generated in the first pass of rcc.
Enable AUTOMOC for tests/auto/cmake/test_add_big_resource to cover this
situation.
Pick-to: 6.1
Fixes: QTBUG-85051
Change-Id: I6d2ce4953297db0751913456db0a4a126fe33f14
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's very likely that we'll have to run certain finalizer code for
targets other than executables.
Rename qt_finalize_executable to _qt_internal_finalize_executable so
it's internal.
Introduce a new function qt_finalize_target which will call the above
internal one when the target is an executable.
This should future proof the API so we have a hook to call code for
any user CMake project that intends to use Qt CMake API.
Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Allow linking all plugin initializer object libraries directly
into the final target (executable or shared library).
The finalizer mode is triggered when the project adds a call
to qt_import_plugins, as well when the project has an explicit
call to qt_finalize_executable or when it is defer called by
CMake 3.19+.
Otherwise the old non-finalizer mode is used, where each plugin
initializer object library is propagated via the usage
requirements of its associated module.
A user can explicitly opt in or out of the new mode by calling
qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE)
The implementation, at configure time, recursively collects all
dependencies of the target to extract a list of used Qt modules.
From each module we extract its list of associated plugins and
their genex conditions. These genexes are used to conditionally
link the plugins and the initializers.
Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the
property even on INTERFACE libraries with lower CMake versions.
QT_PLUGINS is kept for backwards compatibility with projects already
using it, but should be removed in Qt 7.
The upside of the finalizer mode is that it avoids creating link
cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to
duplicate the library on the link line, slowing down link time as well
as possibly breaking link order dependencies.
The downside is that finalizer mode can't cope with generator
expressions at the moment. So if a Qt module target is wrapped in a
generator expression, it's plugins will not be detected and thus
linked.
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Instead of compiling the plugin initializers as part of a user
project, pre-compile them as object libraries while building Qt.
The installed object libraries can then be used with
target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>)
so that they are linked into the final executable or shared library
via qt module usage requirement propagation.
This reduces the build times of user projects.
The link line placement of the object files should be correct for all
linux-y linkers because the only dependency for the object files is
Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that
from empirical observations.
As a consequence of the recent change not to link plugin initialization
object files into static libraries, as well not having to compile the
files in user projects, we can get rid of the
_qt_internal_disable_static_default_plugins calls in various places.
A side note.
Consider a user static library (L) that links to a Qt static library
(Gui) which provides plugins (platform plugins).
If there is an executable (E) that links to (L), with no direct
dependency to any other Qt module and the intention is that the
executable will automatically get the platform plugin linked,
then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage
requirements are propagated successfully.
This is a limitation of using
target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>)
which will propagate object files across static libraries only if
qt_module is linked publicly.
One could try to use
target_link_libraries(qt_module
INTERFACE $<TARGET_OBJECTS:plugin_init>)
which preserves the linker arguments across static libs even if
qt_module is linked privately, but unfortunately CMake will lose
dependency information on Core, which means the object files might be
placed in the wrong place on the link line.
As far as I know this is a limitation of CMake that can't be worked
around at the moment.
Note this behavior was present before this change as well.
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The BASE argument of qt_add_resources now denotes the root point of the
alias of the file. Before, BASE was merely prepended to every file that
got passed to qt_add_resources.
Old behavior:
qt_add_resources(app "images"
PREFIX "/"
BASE "../shared"
FILES "images/button.png")
Alias is "../shared/images/button.png", and pro2cmake generated
QT_RESOURCE_ALIAS assignments to fix this.
New behavior:
qt_add_resources(app "images"
PREFIX "/"
BASE "../shared"
FILES "../shared/images/button.png")
The alias is "images/button.png". No extra QT_RESOURCE_ALIAS assignment
is needed.
The new behavior is in effect for user projects and for Qt repositories
that define QT_USE_FIXED_QT_ADD_RESOURCE_BASE. Qt repositories will be
ported one by one to this new behavior. Then the old code path can be
removed.
Pick-to: 6.1
Task-number: QTBUG-86726
Change-Id: Ib895edd4df8e97b54badadd9a1c34408beff131f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When versionless targets are used, they are defined as INTERFACE
IMPORTED targets. These will sit between the executable target created
by qt6_add_executable() and the underlying Qt6::XXX module library
where the finalizers are defined. We need to recurse through the link
dependencies to ensure we pick up these finalizers. This will also
ensure we pick up finalizers in deeper targets from transitive
dependencies.
Fixes: QTBUG-93387
Change-Id: If8524ebf0e75c8790858dd7e42aa1cf4ebdfd989
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Now that we run tests for static Qt builds in the CI, it makes sense
to restore the CMake build tests that check that static plugin
importing works correctly.
Resurrect the previously commented out test_import_plugins project and
port the mockplugins qmake projects to CMake.
mockplugins is a CMake project that uses the internal Qt CMake API to
build and install some Qt modules and plugins.
test_import_plugins depends on that test (via a CMake fixture) to
build public projects that use those plugins.
The installation of the mockplugins modules pollutes the Qt install
prefix, but in the CI that only happens on the test VM, which means
the release packages are not affected.
Locally on a developer machine the Qt install path will be polluted,
but it's not that much of a big deal. We could try and address that in
a future change by using the QT_ADDITIONAL_PACKAGES_PREFIX_PATH
functionality added for Conan to allow the installation of Qt packages
into a non-standard prefix.
Task-number: QTBUG-87580
Task-number: QTBUG-92933
Change-Id: I0841064a60a5ffba5118640d3197527a38ba6c30
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
QT_TOOL_PATH_SETUP_COMMAND is used in COMMAND list when call
add_custom_command/add_custom_target. This is necessary to setup
the necessary environment for the tool to run correctly. This approach
is weak according to CMake documentation:
"If more than one COMMAND is specified they will be executed in
order, but not necessarily composed into a stateful shell or
batch script."
This change introduces the _qt_internal_wrap_tool_command function
that uses a wrapping script that setups necessary environment for
the tool and runs it in a single shell.
The script is generated by the _qt_generate_tool_command_wrapper
function.
Change-Id: Id5270b91619b607a0c1e3a19b8c706edec43f388
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Introduce the function that appends the specified properties of the
one target to the another. It's possible to copy the standard
property set that affects a compilation only or pass some specific
properties that need to copy. You may also control the visibily of
properties that need to copy by passing the PRIVATE_ONLY or
INTERFACE_ONLY option.
The function is used to compile the resource targets with the same
property set as the main target. Also link the Qt::Platform interface
library to collect platform specific properties.
Pick-to: 6.1
Change-Id: I727fd0a4bc52c4f5128f28ce796d7a5f3005bb30
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Linking the object resource library to the static library still
causes an issue if the static library contains symbols that are
used in the resource library. The proposed approach creates the
following linker chain:
executable <- resource objects <- static library <- Qt::Core
For the static qml plugins this means that the qmlcache_loader
object file will state in the linker command line before the
plugin library that implements '::qmlData' and
'::aotBuiltFunctions' functions.
We also need to keep the INTERFACE linking of the resource library
to the targets that it belongs too, to collect all the dependencies
that resouce library supposed to propagate to top-level targets.
Pick-to: 6.1
Fixes: QTBUG-93002
Change-Id: Ice0aabb6817317724abeb3db3bb8a954905cfad1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add an iOS specific plist file like we do for macOS.
If the user hasn't specified a bundle identifier or a development
team id, do what qmake does and query the Xcode preferences file to
pre-populate those if possible.
This allows running
cmake -GXcode ./foo
on a Qt example project and building it with xcodebuild on the
command line without having to go through the IDE to set a development
team id or modifying the example project to add a product
bundle identifier.
Note that the change assumes that the development team id has been
previously set / configured via Xcode. If no such id is found, then
the value will not be set and the user will still have to specify it
either in the project file or via the Xcode UI after the project
has been generated.
Amends 3a2fa3fec5
Pick-to: 6.1
Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
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>
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 aa4a1006cb
Pick-to: 6.1
Fixes: QTBUG-92361
Task-number: QTBUG-88763
Change-Id: Iae806024ddd5cf10cfe58ddbcebd2818084b0bd7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
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>
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>
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>
This reverts commit 74f549b402.
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>
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>
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>
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>
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>
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>
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>
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>
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 54d0ca93bc)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
__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>
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>
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>
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>
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>
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>
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>
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 113f1ad324
Task-number: QTBUG-88004
Change-Id: Icd95b28ca3642434cf21e5c49dcbd1ec65d76252
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
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>
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>
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 c3fee0d984
Task-number: QTBUG-87661
Change-Id: I03bbb1451de8e54be4e075f878ed104c287aa93f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
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>
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>
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>
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>
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 6fbeef4c6b
Fixes: QTBUG-86858
Change-Id: Ib15f50351a8742c44d7a8be84be4e576cb48bddb
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>
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>
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>
Joerg Bornemann
Alexandru Croitor
Craig Scott
Alexey Edelev
Lorn Potter
Cristian Adam
Tor Arne Vestbø
David Skoland
Mårten Nordheim