Before we only exported features that had outputType PUBLIC or PRIVATE
on the various "QT_ENABLED_PUBLIC_FEATURES" target properties.
Now we also export features that have output type privateConfig,
publicConfig and publicQtConfig.
The new properties names are:
- QT_QMAKE_PUBLIC_CONFIG for outputType == publicConfig
- QT_QMAKE_PRIVATE_CONFIG for outputType == privateConfig
- QT_QMAKE_PUBLIC_QT_CONFIG for outputType == publicQtConfig
These need to be exported for 2 reasons:
- other modules that need to check the config values
- in preparation for generating proper qmake .prl and .pri
information for each module
Note that the config values are now considered actual features
when doing condition evaluation. So if there exists a feature "ssse3"
with outputType privateConfig, its enabled state can be checked via
QT_FEATURE_ssse3 in consuming modules (but not in the declaring
module).
These config values are also placed in the respective
QT_ENABLED_PUBLIC_FEATURES, QT_ENABLED_PRIVATE_FEATURES properties
when exporting a target, so the properties will now contain both
features and config values.
In order to make this work, feature name normalization has to happen
at CMake time, rather than done by the python script.
This means that features like "developer-build" need to retain the
dash in the qt_feature(), qt_feature_definition() and
qt_feature_config() calls, rather than generating "developer_build"
as the script did before.
The normalization is done at CMake time. Feature conditions,
CMake code, and -DFEATURE_foo=bar options passed on the command line
should still use the underscore version, but the original name is used
for the QT_QMAKE_PUBLIC_CONFIG properties.
Note that "c++11" like features are normalized to "cxx11".
Implementation wise, the configurejson2cmake script is adjusted to
parse these new output types.
Also QtBuild and QtFeature are adjusted to save the config values
in properties, and re-export them from GlobalConfig to Core.
Task-number: QTBUG-75666
Task-number: QTBUG-78178
Change-Id: Ibd4b152e372bdf2d09ed117644f2f2ac53ec5e75
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Tested locally with the following configurations:
- iOS device builds (arm64)
- iOS simulator builds (x86_64)
- iOS simulator_and_device builds (fat arm64 and x86_64 archives)
All iOS builds currently require a custom vcpkg fork which contains
fixes for building the required 3rd party libraries.
qtsvg, qtdeclarative, qtgraphicaleffects and qtquickcontrols2
have also been tested to build successfully.
simulator_and_device builds are also supported, but require an umerged
patch in upstream CMake as well as further patches to vcpkg.
Task-number: QTBUG-75576
Change-Id: Icd29913fbbd52a60e07ea5253fd9c7af7f8ce44c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Ran make format.
Change-Id: Ib4fc021c30834a69a9a5df653435dd92dc6a9c05
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Update configurejson2cmake.py to also write out the libraries compile
tests depend on.
Change-Id: I22dbc227a33b9b5d39a2198c6ee6062e7e1bf3de
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
We cannot use a generator expression in an if statement, it does not
work. Instead, we could inspect the CMAKE_C/CXX_COMPILE_FEATURES list,
but unfortunately that's not reliable. For example it detects that ICPC
supports C++17 when in fact that depends on the installed libstdc++.
Therefore this patch revives our own configure tests.
Change-Id: Ic3bc5762fbe81837722523e3881ac16e84628519
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Note the following bigger things that had to be done:
Handle GSS library / feature with a new custom find module.
Implement rudimentary support for relocatability (does not currently
handle extprefix).
Change-Id: Ic6cd27dda7ebca9829f51cb42ea76fff6d1767ef
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
At least setting the example install dir looks like a bug.
Change-Id: Ibcced739d05de5445fa455e509cc6f42b9ed935b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Try not to override built-ins, the code becomes confusing to editors and people.
Change-Id: I9e9421e1506a206551ccfc550f882a075e208181
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
Generate appropriate qt_config_compile_test() calls for config tests
that have CMake projects. These are protected by an if(EXISTS) check
so that configuration doesn't fail for repos where the config tests
have not been ported yet.
Adjust the qt_config_compile_test() function to use try_compile for
projects specified via new PROJECT_PATH argument.
Change-Id: I83c061e384f68688a654b782fd7a9bede282d1e3
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Second and final batch of changes related to string
formatting styling.
Change-Id: Ifc0e999ee95fe52fd076ac2f001b4a58f82ab5be
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
flake8 was used to evaluate the file, with a couple of exeptions:
E501,E266,W503
black was used to reformat the code automatically
The changes were:
* Added a README that explains how to use pipenv and pip,
* Remove unnecessary return statements,
* Remove '\' from the end of the lines,
* Use f-strings (>= 3.6) since we are requiring Python 3.7,
* Commenting unused variables,
* Adding assert when Python >= 3.7 is not being used,
* Wrapping long lines to 100 (Qt Style),
* Re-factoring some lines,
* Re-ordering imports,
* Naming `except` for sympy (SympifyError, TypeError)
Change-Id: Ie05f754e7d8ee4bf427117c58e0eb1b903202933
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We use
qt_find_package(harfbuzz PROVIDED_TARGETS harfbuzz::harfbuzz)
which would set harfbuzz_FOUND. Since variable names are case-sensitive,
this is also the name we must check for in the qt feature condition.
Change-Id: I43420489c3310bc9c3e5cc798a005c8d5b0ab646
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The libclang test is implemented as a custom FindWrapLibClang module.
The module does mostly the same things as the configure test in qmake
land.
Change-Id: I965f284baf7daef074e22f033047c35a917c8808
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When a feature generates a private feature, we should not just repeat
the condition but also make it depend on the original feature. In qmake
features had different outputs, while we have a 1:1 mapping. For example
the developer_build feature had "private_tests" as an output feature.
There's no condition attached to the feature and auto-detect is off, so
we'd generate
qt_feature("developer_build" AUTODETECT OFF)
qt_feature("private_tests" AUTODETECT OFF)
and that's wrong, because when the user enables the visible feature
(developer_build) we want it to propagate to the private_tests feature.
Change-Id: Id8408864802fa1e1ed9e67a5f47d1d2fde38d321
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The auto-generated add_subdirectory conditions in qtimageformats use
QT_FEATURE_foo and not QT_FEATURE_system_foo.
But the non-system ones don't actually check if the respective
qt_find_package(TIFF) got found.
Fix the conditions of the non system features to be the same as the
system ones.
Change-Id: I96f889cf7061721b829d562707c42aa0e29720df
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Some features check for module / target existence. Adapt conversion
script to handle that.
Reland after fixing it.
Change-Id: If4fb942c2e0d16e76a0b9b767bf478527851b0f7
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
It breaks some conditions, and then the build fails not finding
some private header files in qpa, etc.
This reverts commit 35dc8f496d.
Change-Id: I1b51eac06fe9186181d3f0a7c78f22da7be534e2
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Some features check for module existence. Adapt conversion script
and QtBuild feature condition parser to handle that.
Change-Id: I063e49a6fe9f8e9cf3aec985fd78ed4430398586
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The features are reused in qtdeclarative (and maybe somewhere else
too), so they should be present. We can still map the conditions
to proper CMake compile feature tests.
Change-Id: I4d307d29d4d293cc23ab005b195ea346087c7162
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
These were some hard requirements while porting QtQml .pro files so
that the generated CMake code is syntactically correct and the result
buildable.
This include handling of a few more different condition scopes
and disabling the c++ make_unique feature test.
Change-Id: Iae875ffaf8d100296e8b56b57d076455e5d72006
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Some configure.json files contain new lines inside quoted strings,
which is not conformant with the JSON spec.
Add a new json_parser python module which uses pyparsing to preprocess
the json files to remove the new lines inside the quoted strings, and
then hands over the preprocessed content to the regular json module.
Change-Id: I5f8938492068dda5640465cc78f5a7b6be0e709a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
It doesn't make much sense to look for X11 related packages on
macOS and Windows by default. Usually they would not be there, and
as a result the configuration step would show a long list of scary
not found packages, and also eat precious configure time.
Change the conversion script to allow putting conditions around
generated find_package calls.
These conditions can be manually set in the conversion script
library mapping, using the emit_if argument,
which we do for the X11 and Wayland related packages.
They are also computed by checking which features use a given library,
and if the feature is protected by a simple emitIf condition like
config.linux, the relevant library find_package call will be protected
by the same condition.
If a developer still wishes to look for all packages, they can define
the CACHE variable QT_FIND_ALL_PACKAGES_ALWAYS to ON.
The relevant configure.cmake files are regenerated in this patch.
Change-Id: I6f918a94f50257ec41d6216305dae9774933389a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Extract code to write find_package lines from configurejson2cmake.py
and move this over into helper.py.
Change-Id: Iefd313b2a56cb78a99a7f3151c3f6c6284482f79
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Fix library substitution again which broke when I merged all the
library related pieces of information.
Keep Qt and 3rdparty libraries separate so that dbus does not get
mapped into Qt::DBus (or the other way around).
Make names in helper.py more consistent while at it.
Change-Id: I5e5bf02bdabf8bafe991c5701deca76bde4df2c3
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>
Do not set properties of packages to type OPTIONAL. That is the default
anyway.
Update generator script and generated files.
Change-Id: I7a4d043b69c93ce8c2929a2e27ac6a07e4e6d8cc
Reviewed-by: Simon Hausmann <simon.hausmann@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>
With qmake if we don't find a system package, we use the bundled one.
With CMake we don't provide a bundle freetype, hence it's required
to find a system one (or custom provided one).
Change-Id: I00a5e2ac55459957dae0729f89bafa792a102152
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Handle dlopen properly. Code is ifdef-ed on it, so we need it:-/
Change-Id: I7f35d24b97530796a4cdcdc1acbe139757170215
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
This is used to set the default QPA platform and without it
all Gui applications trigger an assert in QString:-/
This is way simpler than going through configure.json.
Change-Id: I2c053e95c0f7e99e97a0b2918d8e4ac13d3494fd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The feature used to be implicitly enabled because qt source ships with
ANGLE sources, and thus ANGLE could always be built. Yet because the
CMake port of ANGLE is not done yet, and because the feature is
implicitly enabled, the build failed when trying to find GLES headers.
To provide a nicer out-of-the-box configuring of the Windows build,
disable the opengles2 feature on Windows, to default to a desktop GL
build. It can be re-enabled once (if) ANGLE porting is done.
After this change, you shouldn't need to pass any additional custom
FEATURE_foo options to cmake to build qtbase on Windows.
Change-Id: I94c96d8ef70cf671d2ce0198311f70b55fa642b1
Reviewed-by: Liang Qi <liang.qi@qt.io>
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>
There were a few cases of feature outputs that were handled
incorrectly before this change, specifically:
- publicFeatures and privateFeatures with custom names
- privateFeatures that also ended up writing defines into
public headers
- publicFeatures that ended up in private headers
- internal features (that should have no QT_FEATURE_foo
defines) that were still written to either public or
private headers
The change takes care of all those cases by keeping a map
of which features need to be written along with any visibility
specifications, as well as custom name changes.
Change-Id: I37baeaeacdfe4935128a392c72ca71b5c3ca1c8d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Remove system-harfbuzz feature and use harfbuzz feature as system
Change-Id: I441345a667450f1c2d19380b0709911011c7ceb7
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
And add the eglfs_x11 plugin
We need to actually try to compile the test as the comment it it says
that having x11 and egl is not enough since sometimes they are actually
incompatible
Change-Id: If6bdc08c21b91fa9c41663f2fa653fd59e5ddd2e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
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>
