461020a86a
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> |
||
|---|---|---|
| .. | ||
| tests | ||
| cmakeconversionrate.py | ||
| condition_simplifier_cache.py | ||
| condition_simplifier.py | ||
| configurejson2cmake.py | ||
| generate_module_map.sh | ||
| helper.py | ||
| json_parser.py | ||
| Makefile | ||
| Pipfile | ||
| pro2cmake.py | ||
| pro_conversion_rate.py | ||
| qmake_parser.py | ||
| README.md | ||
| requirements.txt | ||
| run_pro2cmake.py | ||
| special_case_helper.py | ||
CMake Utils
This directory holds scripts to help the porting process from qmake to cmake for Qt6.
Requirements
- Python 3.7,
pipenvorpipto manage the modules.
Python modules
Since Python has many ways of handling projects, you have a couple of options to install the dependencies of the scripts:
Using pipenv
The dependencies are specified on the Pipfile, so you just need to run
pipenv install and that will automatically create a virtual environment
that you can activate with a pipenv shell.
Using pip
It's highly recommended to use a virtualenvironment
to avoid conflict with other packages that are already installed: pip install virtualenv.
- Create an environment:
virtualenv env, - Activate the environment:
source env/bin/activate(on Windows:source env\Scripts\activate.bat) - Install the requirements:
pip install -r requirements.txt
Contributing to the scripts
You can verify if the styling of a script complaint with PEP8, with a couple of exceptions:
Install flake8 (pip install flake8) and run it
on the script you want to test:
flake8 <file>.py --ignore=E501,E266,W503
E501: Line too long (82>79 characters),E266: Too many leading '#' for block comment,W503: Line break occurred before a binary operator)
You can also modify the file with an automatic formatter,
like black (pip install black),
and execute it:
black -l 100 <file>.py
Using Qt's maximum line length, 100.