3680d3453c
The CONFIG_MODULE_NAME option to qt_internal_add_module is used to specify what the name of a Qt module's pri file should, as well as some of the key names assigned in that file, as well as what should be passed to QT += in qmake projects. When it is not specified, the computed value is the lower case of the CMake target name. E.g. for qt_internal_add_module(Core), the computed CONFIG_MODULE_NAME is 'core'. The qmake variable that determines the above value is the MODULE variable. If it is not explicitly assigned, it's computed from the .pro file name, rather than from the TARGET variable value. Thus there is an inconsistency in how the value is auto-computed in CMake compared to qmake. We had a few special cases in projects that assign a correct CONFIG_MODULE_NAME when the auto-computed value was wrong. Teach pro2cmake to detect these inconsistencies and pass a correct CONFIG_MODULE_NAME value based on the .pro file name. This way we get rid of the special cases as well. Aka if there is no explicit MODULE assignment in the .pro file, and the auto-computed value by CMake is different from the one computed by qmake, explicitly write out a CONFIG_MODULE_NAME value with what qmake would have computed. Task-number: QTBUG-88025 Change-Id: I166b29767e87cd6b0c681fa53238098355a177f9 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> |
||
|---|---|---|
| .. | ||
| accessibilityinspector | ||
| aglfn | ||
| cmake | ||
| corelib/qurl-generateTLDs | ||
| edid | ||
| glgen | ||
| gradientgen | ||
| harfbuzz | ||
| includemocs | ||
| integrity | ||
| lexgen | ||
| locale_database | ||
| plugintest | ||
| qfloat16-tables | ||
| unicode | ||
| x86simdgen | ||
| xkbdatagen | ||