Implement some aspects of qt_parts.prf to simplify the top-level
CMakeLists.txt for repositories that follow the common qt structure
(src, tools, tests, examples).
Change-Id: Ia35f4e9207e92c1cf0406353561b0cc52dcb0e59
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some qt modules need to find 3rd party packages for which there
are no Config files. We need to write custom CMake Find modules to
find those packages. These find modules need to be installed so that
they are used when a user consumes the Qt packages.
Automatically include and install these find modules if they exist,
as part of qt_build_repo_end().
Change-Id: I14aad35ed2999cac8bdda65ca4aeaf74d04fdb71
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
QT_CMAKE_EXPORT_NAMESPACE is used by the Qt packages to make features
available to the consuming CMake project. The value was moved to the
BuildInternals Config file, but that's wrong because consuming
applications not including the BuildInternals component would fail
to use any other Qt package.
Move QT_CMAKE_EXPORT_NAMESPACE to be propagated with QtCore package
again.
Amends 9542e78525.
Change-Id: I9841ac8c2828b00c0111d59e8976c889554e0ce1
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Current lates CMake has a limitation that it does not allow exporting
custom properties from INTERFACE libraries. GlobalConfig is such a
library, which means that so far all the global features were not
actually exported.
Copy the feature property values from GlobalConfig to Core. Because
Core is an actual shared library, it keeps the custom properties
when exported, and thus Core feature properties will contain the sum
of Core and GlobalConfig feature values.
Change-Id: Idde305cbaf9ab85ecfbe29522dcbac1c44022b17
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The GlobalConfig target is not an actual module, so there's no point
in trying to create forwarding headers for GlobalConfig's qconfig.h
within qt_feature_module_end.
qconfig.h's forwarding header will be created implicitly while
processing QtCore target's SYNCQT.INJECTIONS value, which is read
from the headers.pri file generated by syncqt.
This also fixes trying to create forwarding headers when processing
the sqldrivers project.
Amends 02a015375a.
Change-Id: Ifd70d8c3ebf881ffdcf90db8d5d3b23309bc8fed
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Once qtbase is built and installed, save the CMAKE_INSTALL_PREFIX
that was used during the build, and set it when a consumer calls
find_package(Qt5BuildInternals).
This fixes a bug where syncqt can not be found when building qtsvg,
while the developer specifies CMAKE_PREFIX_PATH to find the Qt packages,
but does not set the CMAKE_INSTALL_PREFIX.
Task-number: QTBUG-75544
Change-Id: I03fd23ba418af5115105610f3f9ed92664562945
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
To implement this, create a new Qt5BuildInternals package.
All child Qt modules like qtsvg should use
find_package(Qt5BuildInternals) or
find_package(Qt5 COMPONENTS BuildInternals) in the their
top level CMakeLists.txt.
This will make the qt_build_repo() macros available.
For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH
pointing to the source folder that contains the BuildInternals
package.
For the other modules we actually use a configured and installed
package Config file.
This change moves variables that used to be written into the
QtCore Config file into the BuildInternals package. This way
things that are relevant only for building additional Qt modules
does not pollute the QtCore package.
Task-number: QTBUG-75580
Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Currently to build qtsvg we have some copy-pasted code to set up
the paths for QtSetup and QtPostProcess to be found.
To make it cleaner, introduce two new macros called
qt_build_repo_begin and qt_build_repo_end(). The first one
should be called in a child repo like qtsvg, right after
a find_package(Qt5) call, and the second one at the end of the
repo top-level CMakeLists.txt file.
In order for the macros to work, extract some of the variables
which were set in Qt5Config into Qt5CoreConfig instead. This
makes sure that it works also for find_package(Qt5Core) calls.
Task-number: QTBUG-75580
Change-Id: I85267c6bd86f9291ec2e170fddab1006ab684b5c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
A non-prefix build is a build where you don't have to run
make install.
To do a non-prefix build, pass -DFEATURE_developer_build=ON when
invoking CMake on qtbase. Note that this of course also enables
developer build features (private tests, etc).
When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable
will point to the qtbase build directory.
Tests can be run without installing Qt (QPA plugins are picked up from
the build dir).
This patch stops installation of any files by forcing the
make "install" target be a no-op.
When invoking cmake on the qtsvg module (or any other module),
the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build
directory.
The developer-build feature is propagated via the QtCore Config file,
so that when building other modules, you don't have to specify it
on the command line again.
As a result of the change, all libraries, plugins, tools, include dirs,
CMake Config files, CMake Targets files, Macro files, etc,
will be placed in the qtbase build directory, mimicking the file layout
of an installed Qt file layout.
Only examples and tests are kept in the separate module build
directories, which is equivalent to how qmake does it.
The following global variables contain paths for the
appropriate prefix or non prefix builds:
QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR,
QT_CONFIG_INSTALL_DIR. These should be used by developers
when deciding where files should be placed.
All usages of install() are replaced by qt_install(), which has some
additional logic on how to handle associationg of CMake targets to
export names.
When installing files, some consideration should be taken if
qt_copy_or_install() needs to be used instead of qt_install(),
which takes care of copying files from the source dir to the build dir
when doing non-prefix builds.
Tested with qtbase and qtsvg, developer builds, non-developer builds
and static developer builds on Windows, Linux and macOS.
Task-number: QTBUG-75581
Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
for pkgconfig it is different if they are not defined vs an empty string
Change-Id: Ifb05db5dab32a699aafa32d91f9719eab78dee44
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
DBus1 (1.12) configuration file breaks PKG_CONFIG environment
variables and will thus prevent other libraries to be picked up
by pkgconfig. Main sympthom is that xproto is not getting picked
up anymore, which results in hundreds of lines of warnings about
this being printed.
Work around that by wrapping the call to find_package(DBus1) and
restoring the environment.
Change-Id: Ia69f10b014dddc32045b40972500a843e5d29b38
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Separate the logic to find all used libraries from the code that writes out
the link_library information into the CMakeLists(.gen)?.txt files.
This patch will remove some "PUBLIC_LIBRARIES Qt::Core" from generated files.
This is due to us handling some Qt libraries in special ways in some of our
add_qt_* helpers. These special libraries were added to the LIBRARIES section,
but actually they should be added to the PUBLIC_LIBRARIES section instead. Do
so now, so that the newly generated files do not break things again.
Change-Id: I588781087a8aecc4d879e949735671d8085f0698
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
vcpkg and upstream CMake find module define different target names for
the same package. To circumvent this, create our own Wrap find module,
and link against it. Inside the find module, try both target names.
Change-Id: Iba488bce0fb410ddb83f6414244f86ad367de72b
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Tested with MinGW 7.3.0 64 from Qt 5.12 installation.
The CMake 3rd party libraries I used from hunter project (with some
package, and target names changes)
Change-Id: Ie89555a6cd8bdb7182f9b2dd2c3c39784c523ead
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously we just recorded that Gui has to link against
Vulkan::Vulkan_nolink, but if an application consumed Gui, it wouldn't
find that target.
We need to record that if a module links against Vulkan_nolink, and
then generate a find_dependency(Vulkan) call in the module config
file.
We also have to assign the _nolink interface library to an export
(the Qt5 one), so that it gets installed as a target.
Change-Id: Icbc29ff4161ab18fdd162196ae128e29c1ee8c80
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Generate CMake config files which export Qt targets with a Qt:: prefix
(i.e. without a major version suffix in the namespace)
Change-Id: Ia07f98be6d0e24c196e3880b7469f1f0c6232c06
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Merge all data related to mapping libraries into one data structure
in helper.py.
Use that data for everything related to library mapping.
This change enables way more features now like e.g. adding find_package
calls into generated files.
Change-Id: Ibbd2a1063cbeb65277582d434a6a672d62fc170b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Also needs the include/ from the top-level binary dir added to the
include path.
Change-Id: I7e0d82a2ee24d9bf9ffe9da5fd02b3b223fd48e7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is needed because dependencies added after add_qt_module with extend_target
are currently not taken into account.
Task-number: QTBUG-75538
Change-Id: I2c72207fb88b2480e41a2c8550978fb194275617
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* When using a sysroot, just setting CMAKE_PREFIX_PATH to the
QT_HOST_PATH is not sufficient in finding for example Qt5CoreTools
because the QT_HOST_PATH would be prefixed by the sysroot. So this
patch switches the mode to also enable looking outside of the sysroot.
(done by Alexandru)
* Once the Qt5CoreToolsConfigVersion.cmake was found, the built-in check
for 32 vs. 64 bit compatibility by looking at the provided
CMAKE_SIZEOF_VOID_P (4 when target is armv7 for example) and comparing
it against the void* size used when building the tools would fail.
Explicitly unsetting CMAKE_SIZEOF_VOID_P disables this check, and
that's fine as we're not interested in any exported library targets --
where this could cause problems -- but merely programs to run.
Change-Id: If2931dad023e39a3dbdaa17ac095131ad2c0ca60
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is because some FindPackage may produce some targets only on some
platforms - e.g. qt_find_package(OpenGL) needs to define
the provided target OpenGL::GLX which will only exist on linux but
is required by various CMakeLists.txt files.
Change-Id: I74515470f5d56c246f489df74901ad4223a92a70
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Also make the tool package depend on all tool packages that correspond
to the qt module dependencies.
So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools).
And find_package(Qt5WidgetsTools) will call find_package for
Qt5GuiTools, and Qt5CoreTools.
This enhances the user experience, so that in modules like qtsvg, you
don't have to specify both find_package(Qt5Widgets) and
find_package(Qt5WidgetsTools), but only the former.
Or when cross building, you only need to specify Qt5WidgetTools, to get
both Core and Gui tools.
Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This change introduces a new function called qt_find_package()
which can take an extra option called PROVIDED_TARGETS, which
associates targets with the package that defines those targets.
This is done by setting the INTERFACE_QT_PACKAGE_NAME and
INTERFACE_QT_PACKAGE_VERSION properties on the imported targets.
This information allows us to generate appropriate find_dependency()
calls in a module's Config file for third party libraries.
For example when an application links against QtCore, it should also
link against zlib and atomic libraries. In order to do that, the
library locations first have to be found by CMake. This is achieved by
embedding find_dependency(ZLIB) and find_dependency(Atomic) in
Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake.
The latter is picked up when an application project contains
find_package(Qt5Core), and thus all linking dependencies are resolved.
The information 'which package provides which targets' is contained
in the python json2cmake conversion script. The generated output of
the script contains qt_find_package() calls that represent that
information.
The Qt5CoreDependencies.cmake file and which which dependencies it
contains is generated at the QtPostProcess stop.
Note that for non-static Qt builds, we only need to propagate public
3rd party libraries. For static builds, we need all third party
libraries.
In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any
scope, the targets on which the property is set, have to be GLOBAL.
Also for applications and other modules to find all required third
party libraries, we have to install all our custom Find modules, and
make sure they define INTERFACE IMPORTED libraries, and not just
IMPORTED libraries.
Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
CMake will now generate config and target files for each module that
provides tools. As a result, namespaced global targets such as
Qt5::moc or Qt5::rcc can be made available.
Third party projects that require just these tools, and not the Qt
modules themselves, should specify CMAKE_PREFIX_PATH pointing to the
installed Qt location, and call find_package(Qt5CoreTools),
find_package(Qt5GuiTools), etc.
It is also possible to call
find_package(Qt5Tools REQUIRED Core Widgets) where the last option
is a list of modules whose tools should be imported.
Note that all the tools are in the Qt5::
namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools::
namespace.
This commit also changes the behavior regarding when to build tools
while building Qt itself.
When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when
-DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will
always be searched for and not built.
In this case the user has to specify the CMake variable QT_HOST_PATH
pointing to an installed host Qt location.
When not cross compiling, tools added by add_qt_tool are built from
source.
When building leaf modules (like qtsvg) that require some tool that was
built in qtbase (like moc), the module project should contain a
find_package(Qt5ToolsCore) call and specify an appropriate
CMAKE_PREFIX_PATH so that the tool package is found.
Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH,
the ensure syncqt code was changed to make it work properly with
both qtbase and qtsvg.
Here's a list of tools and their module associations:
qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools
qvkgen -> GuiTools
uic -> WidgetTools
dbus related tools -> DBusTools
Task-number: QTBUG-74134
Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Update required dependencies.
Add section on how to build vcpkg on macOS.
Fix some typos.
Lower required CMake version.
Inform how to bypass annoying ninja reconfiguration issue.
Change-Id: Ia35bd4329c2cbb9857157cdc33b098f5adb04a35
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Otherwise add_qt_executable will still link against Core,
and thus building qmake in a static build will fail.
Amends a1752276e0
Change-Id: Iebbdf9d0a2808a9eaeffdf8fbdb44ff5e2920f3b
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Qmake should not rebuild all the code in QtCore, but currently it does.
When linking against QtCore, all the symbols get duplicated. A clever
linker will "deduplicate" the symbols again, so this actually works
with shared Qt builds, but it fails for static builds.
Do not rely on the linker being clever and just do not link Qt at all
for qmake.
Change-Id: I0f79ed9176a19ee884dd425e5f23c26cf69dc422
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use absolute paths for source files, and relative paths plus a correct
working directory for output files.
This is required to work around a limitation of the dbusxml2cpp tool
where it splits a command line option on a colon ":". Windows paths
contain colons, and that breaks the internal logic of the tool when
passing absolute paths.
Change-Id: Ic653f1317ae4f68bb2f488c117fe48c34310c76e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Applications that have the WIN32_EXECUTABLE property set,
must have a WinMain function. In qmake's case, this function
is provided by the qtmain static library.
Until that is implemented in CMake land, disable the property on
Windows for all qt executables. This fixes the linker issues while
building examples.
Task-number: QTBUG-75195
Change-Id: I323d4dd899f716cd6b9b7f4b5ecb76b22f462fc4
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use an imported target to create _nolink targets. This gets rid of
the need to have an helper target that gets aliases to get work
around the problem of the original target might having a "::" in
its name.
Change-Id: I4618980cf2c673ebf5caca593bccf122b3c81480
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a helper function to QtBuild that generates Foo_nolink versions
of Foo library targets.
Map 'Foo/nolink' libs found in qmake to Foo_nolink.
Automatically run helper function to create _nolink targets as
part of extend_target.
Change-Id: I4c23ea68b3037d23c9a31d4ac272a6bd0565f7c0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The test erroneously succeeds on macOS with an XCode generator.
Explicitly set the test result to be turned off.
Change-Id: Id6fcb96f420f611517e81cc3697f1c88b508bd7c
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Tests and their helpers should only be used in the build directory.
Change-Id: I5aa9fcf734b6b3667f91df7c84d083f944c452c9
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Makes qtextcodec test succeed
Like qmake does
qt_test_helper.prf says
"
If an auto test needs a helper application, this helper should
be put into the same directory as the test itself.
"
Change-Id: I02cb36d2237cdb72912c943250b843c33ffcd64a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This includes:
- tests
- tools that are only used duing the Qt build (tracegen and
qfloat16-tables)
Change-Id: I3a5f678682b5b9318012568a9e4dcdda0967f89b
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This FindCups defines a target, which the FindCups.cmake in the currently
required CMake version does not:-/
Change-Id: I76c5bb72ece80415db1971e4f2079682126fde36
Todo: Remove again once we depend on CMake 3.15.
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is especially important on macOS when doing a debug build,
because QPluginLoader is looking for the cocoa QPA plugin
suffixed with "_debug" when executing a test or example.
Change-Id: Ief23b3a82c567c16ab9dd30d04d1729031262d7d
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The one shipped with cmake is more modern:-)
Change-Id: I024769825467734ff1527e91df4cf5dfc38cbe68
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
The install path takes into account the path structure of the source
directory, so that not all tests are bunched up into /tests, but
rather /tests/auto/foo/bar.
Change-Id: I5e32d2e41ae8f095f4eac6654973508efd598df0
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Only require TYPE if no OUTPUT_DIRECTORY, ARCHIVE_INSTALL_DIRECTORY
and INSTALL_DIRECTORY is provided.
Change-Id: I6db1cfaa576bfa3ee3dc8ecf81db20e3afcd61e2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
While building on macOS, AUTOMOC sometimes hanged indefinitely.
The problem was that AUTOMOC was executed for the qmacstyle
plugin before moc was actually built.
Because of an upstream bug in CMake, AUTOMOC was caught in a deadlock
without reporting that spawning the moc process failed. Specifically
if a libuv spawn() call failed, the condition variable for a waiting
thread was not notified, and the thread kept waiting forever for the
process launch to finish.
Fix the dependency by setting the AUTOGEN_TARGET_DEPENDS property
on all targets that have AUTOGEN tools enabled. This makes sure that
moc and friends are built before they are used.
Also add some special cases to disable autogen tools on certain targets
to break cycles between targets.
Fixes: QTBUG-74636
Change-Id: I6e689e63cba1962525f169f332a58498d173c0a6
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
It broke builds because the qconfig.h file was created in the wrong
directory.
This reverts commit 25f67fbb07.
Change-Id: Ia458ef4193a3985a9ba613d82f679b7df5ca0107
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
This is only a half solution, because some of them need to be set
based on the detected MSVC version and Windows kit, similar to
how it's done by qmake.
Change-Id: Ice13c99d6fe0a033ddfebf9d4be924dcd6b8a36c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In qmake there are at least 2 things to know regarding
sub-architectures and instruction sets.
Which instruction sets does the compiler know to compile for,
represented by the various config.tests and features in
qtbase/configure.json.
And which instructions sets are enabled by the compiler by default,
represented by the configure.json "architecture" test and accessed
via QT_CPU_FEATURES.$$arch qmake argument.
Before this patch there was some mishandling of the above concepts
in CMake code.
The former can now be checked in CMake with via TEST_subarch_foo and
QT_FEATURE_foo (where foo is sse2, etc).
The latter can now be checked by
TEST_arch_${TEST_architecture_arch}_subarch_foo
(where foo is sse2, etc and the main arch is dynamyicall evaluated).
The configurejson2cmake script was adjusted to take care of the above
changes, and the cmake files were regenerated as well.
Change-Id: Ifbf558242e320cafae50da388eee56fa5de2a50c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Presumably this was a copy paste that was not intended.
Change-Id: I09e3bb12b3b3f7af75726d7a952d79814ea9c876
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This amends 4f1a155909 and
37b154858f which caused the regeneration
of some json features to be internal. Some of those features were
not evaluated any more unless they were referenced in another feature.
Make sure to explicitly evaluate all internal features as well.
Change-Id: I4367f309585fe29dc89d8a6b793de381956ae51d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Make add_qt_executable link to Qt::Core by default. Add a BOOTSTRAP
flag to disable this behavior again.
Pass BOOTSTRAP on from add_qt_tool to add_qt_executable.
Change-Id: I26e7f1e03254122f626b3765cccc0dc4414a4fc0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Allow to override the install directory for Qt executables.
Change-Id: I9561976eefe9c7b573bb97ddaaa39e30d3b6d9fb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use the same names for DBus adaptor/interface files that are also
used by qmake. E.g. io.qt.something.xml will be turned into
something_interface.(cpp|h) or something_adaptor.(cpp|h).
Change-Id: I799b8aee7addd1fe590e8f3ec078e5325b68d5b1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Treat a relative path in OUTPUT_DIRECTORY as relative to the top level
build directory, not to the current build directory.
Change-Id: I4d409d1362a8f73d13b93cf5ab98e82e60dd62cb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
- executed pro2cmake script on windows qpa plugin
- added windowsuiautomation platformsupport project
- fixed plugin dlls and lib files to be written to the same path
- fixed an issue comErrorString which used implicit casting
from QString to char*, but plugins are currently built
with QT_NO_CAST_TO_ASCII
Task-number: QTBUG-74140
Change-Id: I5db3b6c5264bbd5dfba2998b049fda36eb312c70
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
- Fix qmake build
- Fix QtNetwork moc-ing, by including the moc files
inside the cpp files
- Fix sql odbc plugin by including QT_PLUGIN define
- Fix Boostrap to link against the Platform target, to get the
correct Unicode and WIN64 defines.
- Fix vulkan headers to be found
- Fix freetype bzip and png unresolved symbols / linker issues
when building minimal platform plugin (also need to make
sure to use the vcpkg toolchain instead of CMAKE_PREFIX_PATH
because then find_package is overridden, which does magic
to properly propagate static library dependencies).
- Fix qfilesystementry test not to be built without private
tests feature (it led to undefined symbols issues).
- Make sure to remove QT_NO_CAST_TO_ASCII define when building
QtCore, so that the qstringbuilder3 test builds
successfully.
Task-number: QTBUG-74140
Change-Id: I353d08392b604d55f8e62cdd8696d1e19a3c084a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Instead of generating defines guarded by feature ifdefs,
record the define information (condition, name, value, etc),
and generate the final define statement only if the feature
condition evaluated to true.
This removes the need to generate feature defines
(QT_FEATURE_foo) for features that have neither public nor
private outputs in the configure.json file.
Also note that all qt_feature_definition() calls
(which correspond to type:"define" outputs in json files)
now generate defines only in the public header, which seems
to be consistent with how qmake evaluates json files.
Change-Id: I5210b405d5735dd9df5f7a55d1ea9547bb7b1159
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Certain features like opengles2 can be enabled or disabled based
on the conditions that are specified in the ENABLE and DISABLE
parameters.
Because some of those conditions use STREQUAL with
a single quoted argument, we have to use
qt_evaluate_config_expression to circumvent the CMake bug
regarding single quotes, which is described in the function
implementation.
Only then will enabling / disabling work correctly.
Change-Id: I3b68ef611c985f0d8416fd089055fd862da1e542
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The script used to write incorrect dependency headers due to not
clearing the qtdeps variable at each loop step.
Change-Id: Icf293be7cea596daa096ab19d390c0bb468a8654
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* Handle BASE to give the directory files will be relative to.
* Support lang="foo" for qresource sections.
Change-Id: I36087220d03789a97105dc6dd1aca7a25a063d9f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
moc does not generate moc_defs.h and that's why moc does not understand
that he runs on macOS.
It happens because cmake can not find Qt version.
Change-Id: I34c51ebb69dc1ff782a0f129e114cda819122805
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a function to set gc-sections flags on the linker.
Change-Id: I9ac02364836d2aa8de239adb8d3a5d29659a4007
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Only has warnings for now
Next to come is the support for developer-build and enabling Werror
Change-Id: I8070dc06eb439c2a03007cce975c8147ff7e1582
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Because the default "empty" CMAKE_BUILD_TYPE is a weird default
Change-Id: I5768f67aa85dce4108e421d2f4eacdfb1cb5beb0
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Upstream commit 7c64db9568296e1caafcfd7163cea3ab1b1626ae fixed the
suffix path checking and thus the build on FreeBSD.
Change-Id: I0cceeac0639c2899c617ffd6359098d2154acf5b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Pass -DQT_USE_CCACHE=ON to enable the use of ccache. This avoids having
to set up symlinks, which is useful when cross-compiling against
different targets.
Change-Id: I023fff105baaa538730997948aa122d2678887ce
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Don't try to build uic but instead import it. This is done centrally now
in add_qt_tool.
Change-Id: I241fbb924de68549e9c0320e157351bd7b1bf5c3
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Public interface libraries of the private target need to be first looked
up via `find_dependency(...)` in the CMake config files as well.
This patch is just changing the foreach() loop and defer the package
config file generation.
Change-Id: Iecaf7f778379b526f12ac6a42e76d714d9349b2c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Lifetime of the variable is bound to the function body. Use a CACHE
variable to escape it (and to speed up future calls to the function).
Change-Id: I2d164a1c94e64cc652e65c1eea0522f3d911ad82
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
... when QtBuild.cmake is being included from another Qt module
Change-Id: Ia55e03422cc84a56dd9eac640621e5b2ee9681bd
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The ECM version now also does a compile test, which was the only real
"functional" difference.
Change-Id: I1d5cd590359feba7c7a38ff374992349d5943070
Reviewed-by: Volker Krause <volker.krause@kdab.com>
This makes it possible to use the binaries out of the box. This is
particularly relevant for program binaries that link against QtCore
dynamically, when trying to use these binaries during cross-compilation.
Change-Id: I7dee93194be3fff5c6e3bbb9e202e4cf5e19b6d0
Reviewed-by: Volker Krause <volker.krause@kdab.com>
Otherwise the cmake summary at the end says
-- The following packages have not been found:
* WrapOpenGL
It's OpenGL or GLESv2 that will show there as missing if needed
Change-Id: I182f1299b86e1a4e24762d0bad6533c6136cbbcc
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The syncqt generated headers are optional, i.e. their source may not
exist -- so for now make their installation optional (as it seems to
have been the case with qmake).
Change-Id: Ieaeb3d13a1d8ff1f158b5b1c918750fec48d3bef
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
This change fixes a few things in one go:
* cmake's FindOpenGL cannot be used reliably to detect EGL. So use a
custom module for that.
* Added a custom module for GLESv2 detection, as cmake's FindOpenGL
does not support that.
* Map CONFIG += opengl to a WrapOpenGL target, which links against
either GLESv2 or libGL - just like mkspecs/features/*/opengl.prf
* cmake's FindOpenGL remains in use solely to detect the availability
of desktop gl.
Change-Id: I9315e5ad1fd88e1b7dc7e920053e98fb51fea7fc
Reviewed-by: Volker Krause <volker.krause@kdab.com>
Added to QtFeature.cmake a way to be able to run feature_module begin
and end without having an actual module by passing NO_MODULE
Change-Id: Ib708bd3878e2591da193d18563c8932cc4b75e7f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This is not quite the correct design yet, but makes the existing
mechanism work first.
Change-Id: Idbc6f1380adc955a772eb6e5beb6b3a5f7f686bb
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
When we do
qt_config_compile_test(egl_x11
LABEL "EGL on X11"
LIBRARIES X11::X11
...
)
then check_cxx_source_compiles() aborts if the provided targets do not
exist (we map LIBRARIES to CMAKE_REQUIRED_LIBRARIES). However we just
want the test to fail. Therefore this patch verifies the presence of the
targets.
Change-Id: Ibd7c1b50d585339af0ca0de58bc5c9cd64d65d6d
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Enables the use of e.g. QT_NO_DEBUG in compiler flags, -fPIC, passing on of
QT_NAMESPACE, etc. pp.
Dropping a lot of custom code which handled adding imported targets for
the command-line tools (this is all being handled by CMake already).
It needs to be investigated if we need to resurrect
Qt5GuiConfigExtras.cmake.in in one way or the other.
Change-Id: I4fa141b68fddaad4f33e628c59d5d0b3a7b3a096
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
For now create targets a la "Qt5::Core" to stay compatible with the
current Qt5 naming scheme. The name is controllable via a CMake option.
Change-Id: If43c058221949b1900c2093f39ccc9d0f38028f1
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
