When checking the value of CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG>,
then <CONFIG> must be the upper case configuration name.
Also, we must not unset __qt_ltcg_detected, because the feature
condition evaluation happens way after the feature definition, and
__qt_ltcg_detected was not available anymore there.
This commit amends 96bdcdacbc.
Fixes: QTBUG-87874
Change-Id: I2b555bd1d7fbc8973e1d9493045c27d61b0d2c1b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change-Id: I47504d6c032c9a6ace7440580f0081cc5f254038
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
In preparation for some further regeneration.
Also modify pro2cmake to add forgotten mapping for the
Qt::EglFsKmsGbmSupportPrivate module.
Change-Id: I92425c566c2b275b40eec8c652496290754ac385
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Requires subsequent re-numbering of the enum tables to eliminate gaps,
before locale data can be regenerated. However, it will work with the
present locale data, since it merely loses the means to use some names
for which the available data was just the name and code. This implies
a transient issue of recognising some codes for which there is no
actual enum member; but relevant code will work as before, finding
nothing but the code and its name. This shall be resolved by a coming
BiC change to resort the language, country and script codes, changing
the numbering (almost) completely.
[ChangeLog][QtCore][QLocale] Various obsolete language and country
codes have been removed. Some lacked locale data, others were obsolete
aliases. All have been deprecated in 5.15.
Task-number: QTBUG-84669
Change-Id: I45fc76a5f2f6c3b0ea3c1bb61e917da984183783
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Now that qt_add_executable doesn't set the WIN32_EXECUTABLE and
MACOSX_BUNDLE properties anymore, pro2cmake needs to look at the qmake
example projects and generate appropriate set_target_properties calls.
The relevant CONFIG entries to look at are windows, console,
app_bundle and cmdline.
CONFIG += windows implies 'subsystem windows' on Windows, which maps
to WIN32_EXECUTABLE == TRUE.
CONFIG += console implies 'subsystem console' on Windows, which maps
to WIN32_EXECUTABLE == FALSE. Aka the opposite of CONFIG += windows.
Whichever is the last one set, cancels out the other one.
CONFIG += app_bundle implies a macOS bundle executable, which maps
to MACOSX_BUNDLE == TRUE.
CONFIG += cmdline is the same as CONFIG += console and CONFIG -=
app_bundle, aka WIN32_EXECUTABLE and MACOSX_BUNDLE set to false.
In qmake, if no CONFIG is specified in an example project,
the default is CONFIG += windows app_bundle, aka WIN32_EXECUTABLE
and MACOSX_BUNDLE set to true.
The script uses a heuristic to try and not write the properties for
every single subscope, except for values different from the default.
This is not strictly correct, but it covers most use cases, and keeps
the generated projects a bit cleaner.
Task-number: QTBUG-87664
Task-number: QTBUG-86827
Change-Id: If05606ec3205e0fe7c1803c07e114d9fd9c3e4f7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Routine update by running scripts, ignoring clang-format's extensive
grumbles. Added notes to util/locale_database/'s README, on the need
for that, and enumdata.py, on when to add entries. As usual, several
new locales are also added, for existing languages, territories and
scripts.
[ChangeLog][QtCore][QLocale] Updated to new version of CLDR (the
Unicode Consortium's Common Locale Data Repository) v37.
Fixes: QTBUG-84669
Pick-to: 5.15
Change-Id: Ib76848bf4bd1219180faf46820077e8d8049a4e3
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The singleton modifier must be written without square brackets.
Task-number: QTBUG-87684
Change-Id: I924bbf97789edd7f2b4f2b9bbca2cb99841d2906
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
The code pervasively presumes their values can be held in a ushort, so
make sure the compiler knows we expect that to work (and doesn't
complain about narrowing when we do convert them to ushort).
Change-Id: Idde7be6cceee8a6dae333c5b1d5a0120fec32e4a
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The script told me the wrong path to pass as first argument, so
correct that; and the README didn't mention the need to run it.
CLDR v37 makes no change to the actual generated data, though.
Tweaked wording of a comment in the script.
Task-number: QTBUG-84669
Change-Id: I56b510c666f414d9719cef650aeec6192c4fde6e
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This time based on grepping to also include documentation, tests and
examples previously missed by the automatic tool.
Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
In order to funnel this through CMakeLists.txt we add an
OPTIONAL_IMPORTS entry in addition to the existing IMPORTS.
Task-number: QTBUG-87130
Change-Id: I57e882e75d17f5bc68d99ce7837425981fe6938b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is necessary for pro2cmake.py to work on qmlcompiler.pro.
Change-Id: I356a6333d3bcc15daf6f2692a2b7ca82c9f37c85
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This option maps to FEATURE_reduce_exports. The feature is on by
default, except for MSVC. The reduce_exports configure test is not used
in the CMake build.
The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target
properties are now explicitly initialized in the
qt_set_common_target_properties function, because we don't have access
to the feature in QtSetup.cmake where the CMAKE_<LANG>_VISIBILITY_PRESET
variables were set before.
Task-number: QTBUG-85373
Change-Id: I378453f0e0665731970016170302871e20ceb4e2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Offer compatibility wrapper functions until we update all of the Qt
repos to use the new names.
Task-number: QTBUG-86815
Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
xcb-image includes xcb_aux.h, which is part of xcb-util.
Fixes: QTBUG-86287
Pick-to: 5.15
Change-Id: I253308008c5baeb1d061ef19f516ae6ab6dff52c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This configure switch sets the CMake variable
CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG> per release config to ON.
The feature 'ltcg' is enabled if any of the variables
CMAKE_INTERPROCEDURAL_OPTIMIZATION,
CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG> are ON.
In order to implement the check, configurejson2cmake had to be extended
to be able to write extra CMake code before and after the feature
definition. This extra code can be added to a feature mapping below the
keys "cmakePrelude" and "cmakeEpilogue".
Task-number: QTBUG-85373
Change-Id: Ia2eb907edcf087f137977a9b090705397f83eb05
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
If '-make examples -no-compile-examples' was specified, sources of Qt's
examples would be installed, but the examples would not be built.
This switch has always been a source for confusion and is only
interesting for distributors, who can just package the examples
directory tree.
Change-Id: I0291d70e4951d98b553a4abf217db49d05316d3a
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Such expressions were translated to "foo NOT = 0" which is invalid code.
Change-Id: I8b485bfe1d1f553c08df3b5d59b0f39f2dcbd5c0
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Calibrated to match F16C and ARM-FP16 hardware conversions.
Change-Id: I3bdd4d3db3046fee4aeb24e4ce8b9bc9a06e0397
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The qmake parser of pro2cmake handles completely commented lines to make
assignments like this work:
SUBDIRS = \
foo \
# bar \
bar
However, assignments like
SUBDIRS = \
foo \
#bar \
bar
were cut off at the commented line.
Fix this by allowing leading whitespace for "fully commented lines".
Change-Id: Ib5de850a02fd9b9ebb7c056c2f64f9d684334b08
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The Unicode table code can only be safely called on valid code-points.
So code that calls it must only pass it valid Unicode data. The string
iterator's Unchecked Unchecked methods only provide this guarantee
when the string being iterated is guaranteed to be valid UTF-16; while
client code should only use QString, QStringView and friends on valid
UTF-16 data, we have no way to be sure they have respected that.
So take the few extra cycles to actually check validity in the course
of iterating strings, when the resulting code-points are to be passed
to the Unicode table look-ups. Add tests that case mapping doesn't
access Unicode tables out of range (it'll trigger the new assertion).
Added some comments to qchar.h that helped me understand surrogates.
Change-Id: Iec2c3106bf1a875bdaa1d622f6cf94d7007e281e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The debug feature for the CMake build is solely determined by the value of
CMAKE_BUILD_TYPE or CMAKE_CONFIGURATION_TYPES. There is no point in
restricting the autoDetect expression to developer builds or MSVC and
macOS builds.
User-visible result: -DCMAKE_BUILD_TYPE=Debug now actually turns the
'debug' feature on, also for non-developer builds on Linux.
Change-Id: I65c92575c9483bff16beb78b60606c55aeadcece
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This configure switch controls the feature 'optimize_size'.
This isn't merely a mapping to CMAKE_BUILD_TYPE=MinSizeRel, because
we potentially want to combine -optimize-size with -force-debug-info,
which maps to CMAKE_BUILD_CONFIG=RelWithDebInfo.
Task-number: QTBUG-85373
Change-Id: I1a9343ebc54816f52e90e9d33ea3df4c99b1ec9f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make clear why we don't need to assert against out-of-bounda accesses
in the generated code, provided the code point is within its bound,
(Using one table's early entries as indices into later in the same
table at which to look up indices into another table made it a little
hard to work out what was going on, especially as nothing told me
about the early / late distinction. Record what I discovered, to save
the next person to stumble into this some confusion.)
Change-Id: I8e5771a7f3d70c1911aeae1b0cabe5c47bc7e9c7
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The configure argument -qreal <type> maps to the CMake argument
-DQT_COORD_TYPE=<type>.
Fixes: QTBUG-83325
Change-Id: I94970f31ccfb241b1dd4f1d9b6cef25d6684dc05
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We extend configurejson2cmake to read the "commandline"
information from configure.json. This data is then translated to CMake function
calls and written it into commandline.cmake files.
We extend QtProcessConfigureArgs.cmake to pick up those commandline.cmake
files to feed our command line handling code, which is a
re-implementation of the command line handling in qt_configure.prf.
The command line handler sets INPUT_xxx variables, similar to
configure/qmake's config.input.xxx variables. The INPUT_xxx values are
translated
- to -DFEATURE_xxx=ON/OFF arguments if the input represents a feature,
- to corresponding CMake variables if such a variable is known,
- or to -DINPUT_xxx=yyy CMake arguments.
Configure arguments that have an entry in
cmake/configure-cmake-mapping.md are actually implemented. Other
arguments are likely to need more work.
Task-number: QTBUG-85373
Change-Id: Ia96baa673fc1fb88e73ba05a1afb473aa074b37d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Both normal and relaxed constexpr are required by our new minimum of
C++17.
Change-Id: Ic028b88a2e7a6cb7d5925f3133b9d54859a81744
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
It's new in Qt 6 after the type registration changes.
Task-number: QTBUG-82922
Change-Id: Id4aa22e50a8d84736688dbf2ab51e12a116177f0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
They were only used by one function each, in unicodetables.cpp, so
don't need to be macros.
Change-Id: I3e7f9f661568862d0a0d265bb8f657a8e0782b13
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Embed package versions into the qt_find_package calls for various
Linux specific packages.
Task-number: QTBUG-82917
Change-Id: I5d1cb623f81932dfae4658b8a3a89eedb71ea3af
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If certain 3rd party libraries have a version that's not suitable for
Qt, the configure summary should say so, rather than use them and fail
at build time.
With the current situation, we have to duplicate the version
information from the configure.json files in helper.py, by assigning
the version number as an extra find_package variable.
Rerunning configurejson2cmake then embeds this version info into the
qt_find_package calls in configure.cmake.
Some of the Find modules are rewritten to take the specified version
into account when looking for the libraries.
This involves moving around the code for creating a target, after
calling find_package_handle_standard_args() so we know if a good
enough version was found.
Task-number: QTBUG-82917
Change-Id: I139748d8090e0630cda413362760034dc3483e11
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Eliminate some needless parentheses, tidy up some spacing and
indentation and split some long lines. Change first += after
declaration to initializer.
Change-Id: I05ff2a6337b7ed14e0a2dc9c03fc784c92b63515
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Qt6 makes sizes qsizetype; and one of these was already sizeof()-sized.
While qsizetype might not be ssize_t, it's at least no bigger, so we
can safely use its format specifier, with a suitable cast.
Change-Id: I433f654f6b139d74b4d5358b804b44ab1f0ada15
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>