According to QUIP-18 [1], all build system files
should be BSD-3-Clause.
The files in this patch are part of the build system.
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: Ibc6a60a9b009fab0c953e8e3269533c121e4511e
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
The check and variable name were incorrect after a refactoring.
Amends ba96238600
Pick-to: 6.6 6.7
Task-number: QTBUG-84884
Task-number: QTBUG-90820
Change-Id: I33b6b81695a6352c7869ef6186e00881b47bd6f3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qt_add_qml_plugin has code to set a sensible install rpath for user
project qml plugins.
If Qt was configured without rpath support, we should not add any
rpaths to qt qml plugins:
- qt-computed rpaths added by qt_apply_rpaths
- user-project rpaths added by qt_add_qml_plugin
This is done by setting QT_NO_QML_PLUGIN_RPATH to TRUE as part of
QtSetup, effectively applying the option to any qml plugin that is
built by internal qt api.
User projects will still be able to use the default rpaths added
by qt_add_qml_plugin, even if qt itself was configured with no rpath
support.
Pick-to: 6.7
Fixes: QTBUG-122687
Change-Id: I8178b527553dd00436d0abb3b44061ea16edc121
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This amends commit be009c6857.
The configure option -no-opengl was mistakenly translated to the CMake
argument -DFEATURE_opengl=no. The command line option "opengl" however
is defined as
qt_commandline_option(opengl
TYPE optionalString
VALUES no yes desktop es2 dynamic
)
which is not boolean. And only boolean command-line options may
automagically control features of the same name. It just happens that
the values "no" and "yes" look boolean.
Setting FEATURE_opengl instead of INPUT_opengl broke feature conditions
that check the INPUT_opengl value.
Fix this by checking the type of the corresponding command line option
instead of guessing the type from the INPUT_* value.
An option (e.g. force-asserts) can be diverted to a differently named
input (e.g. force_asserts) with the NAME argument of
qt_commandline_option. In this case, we cannot deduce the option name
from the input's name. To handle this, we store the input's type in
commandline_input_${name}_type and read it when translating feature
values.
Fixes: QTBUG-122914
Change-Id: Ibb4b0633b6635bd2ef6f26ed8f4b19d239bf5854
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And mention the init-repository --help section for additional options
that can be passed to adjust the cloning process.
This should only be merged after the qt5.git change is merged.
Task-number: QTBUG-120030
Change-Id: I16c36f8d5d5d75521ca3f4a476dd921537f9db9c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
According to QUIP-18 [1], all tools file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: Icd5d5be2e04819617e68ff142924de1773bebbad
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Since the last change to configure.bat we got two of these errors,
regardless of the arguments passed to configure:
The system cannot find the drive specified.
This is due to the quirky semantics of the :: commenting style that's
used within an if block. Lines starting with :: might be interpreted as
starting with a drive letter.
Switch to rem for comments to avoid such behavior.
Note that we have to quote the comments, because
rem https://www.example.com/?foo=bar
will split the command at the equal sign and complain about
'unexpected bar'.
Mind-boggling trivia:
rem https://www.example.com/?something_without_equal
will display the help text for the REM built-in, because /? is somewhere
in the string.
Change-Id: I2ffcc6bd4312d24bdde2b7f1e336f827f503e491
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
According to QUIP-18 [1], all test files should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: If06da73cecbbf718338d1b785b5eca36ac819ccb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
The target wrappers for qmake and qtpaths do not work on Yocto
builds and only create confusion when they are available in target.
Add option to disable their generation.
Pick-to: 6.7
Task-number: QTBUG-122420
Change-Id: Ibb829cc846ad6c470fe29e746ade42fccaa33a6f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The QHttpHeaders comparison was dropped earlier, and the current code
no longer needs to compare both header entry 'name' and 'value'.
Pick-to: 6.7
Change-Id: I57a3003f0fd1d8ff867c970d5ec8a994a167ae88
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
... from a performance point of view.
Pick-to: 6.7
Task-number: QTBUG-122020
Change-Id: I8a1558a46e74d740e330ad483454267f9922a5d5
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This saves memory and can speed up performance with
well-known headers.
The change consists of:
- Change the internal type of 'name' to a std::variant
capable of holding either WellKnownHeader-enum, or a QBA.
- Accordingly, add an equality operator.
- When headers are added (append, insert, replace) then
use WellKnownHeader as storage type when possible;
either use the function parameter directly if a WellKnownHeader
overload was used, or check if the provided string can
be converted to a WellKnownHeader.
- Convert other functions to use a more performant
lookup/comparisons.
Pick-to: 6.7
Fixes: QTBUG-122020
Change-Id: If2452f6edc497547246fb4ddbace384e39c26c5e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
As a prequel to make subsequent diff on the followup
commit (std::variant/union) smaller
Pick-to: 6.7
Task-number: QTBUG-122020
Change-Id: Iaa5dd794dc7a9e33c2c43e459bf5dbd19afb3ba1
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This allows a more performant (O(logN)) lookup for WellKnownHeader
enum (followup commit).
The lookup table is currently crafted manually. It may in future be
generated at compile-time, but this should only be done if new headers
are appended often; we don't want to unnecessarily bloat compilation
time either.
Pick-to: 6.7
Task-number: QTBUG-122020
Change-Id: I0329902b13128f03c358796d5cda7014b1e75057
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Like as QT_QPA_PLATFORM, supports specifying multiple keys, and can
perform fallback operations to prioritize the use of a certain plug-in.
This is useful when using Wayland and XWayland applications at the same
time. For an example, we can set "QT_IM_MODULES=wayland;fcitx", and the
wayland application will use the wayland input context plugin, the
xwayland application will use fcitx, which can't be done without adding
a new environment variable, if we specify "QT_IM_MODULE=wayland", the
XWayland applications may not be able to use the input method.
Fixes: QTBUG-120202
Change-Id: Iac408af241963147747a2fe685f1e27bf9d9ee64
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Try to avoid writing anything that the parser would misinterpret.
Escape pre-existing backslashes, but not those that are already escaped.
Optimize maybeEscapeFirstChar() slightly and apply it to every line
of output (except in code blocks), not only to new lines created by
word-wrapping.
Since it would be hard to do this without using regular expressions,
the markdown writer feature now depends on the regex feature.
Fixes: QTBUG-96051
Fixes: QTBUG-122083
Pick-to: 6.7
Change-Id: I8d95366501fd31441829081c668f11a3a3a23fe2
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The ones in qlogging.cpp were copied to it from qglobal.cpp in commit
23688d8942. They existed in qglobal.cpp
like in qdebug.cpp since the beginning of the public history. The one in
qdebug.cpp already made no sense in Qt 4 times, because qdebug.cpp was a
documentation-only source (no actual C++ code).
The #undefs from qglobal.cpp hadn't been necessary since commit
d394ca7f27, the global functions qDebug(),
qWarning(), qCritical(), etc. were replaced by member functions in
QMessageLogger whose names did not match the macros.
Pick-to: 6.7
Change-Id: I50e2158aeade4256ad1dfffd17b1c62f23eca4db
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The QStringView counterpart is somewhat faster because it doesn't go
through the UTF-16 codec in QUtf16::convertToUnicode(), which tries to
detect the BOM.
I've included QString::fromWCharArray in this because:
a) it's used extensively in Windows code
b) wide chars in memory probably don't have BOMs anyway
Change-Id: I01ec3c774d9943adb903fffd17b815be4d2ab8ba
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
The quotes should be around the whole file path, and not
just around the directory. Otherwise it can cause the
build to fail if Qt lives inside a directory that is
symlinked from a different drive.
Pick-to: 6.5 6.6 6.7
Change-Id: I46e23d4a78c807e6617224ce7faff96e6985f449
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Several of the cmake bat files sets "script_dir_path". The problem
is that those assignments are not local to the script files. E.g
when qt-configure-module.bat gives it a value, and then call
qt-cmake.bat, qt-cmake.bat will assign it a different value. And
this value will overwrite the original value in
qt-configure-module.bat. So when the call returns, that script can
sometimes fail.
This happens (for unknown reasons) if the Qt source code path
contains a link to a different drive, created with mklink /d.
This is typical if Windows is running in a virtual machine, and
the Qt source code is shared with the host on e.g drive Q:.
In that case you might want to a folder on C: be a symlink to Q:, in
order to build Qt.
This patch will make sure we add "setlocal" in all the affected
bat files, so that any changes done to e.g "script_dir_path"
stays local to each file.
Pick-to: 6.5 6.6 6.7
Change-Id: Iee18e06eb0beece0c85c4345d9bfc0194e466e56
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We have certain platforms where we build on one OS version (the
latest) and then test on an older version.
macOS is an example of such a platform.
Set the COIN_CROSS_PLATFORM_VERSION_TEST environment variable to true
for such platforms. They usually have a dependency on the main OS
version and are marked with the TestOnly feature.
This is useful information that can be used by CMake build tests in
order to skip those that do not account for the difference in OS
versions.
Change-Id: I6eeeac98abe6beb00ce431e17589f8e093ed23e4
Reviewed-by: Toni Saario <toni.saario@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We are observing that the strings become sequences of zeros in
release builds, possibly triggered by qOffsetStringArray being used
in a static constexpr function to initialize a constexpr array.
Pull the array out of the function as a static on translation unit level,
which is a pattern we use regularly elsewhere in Qt.
Pick-to: 6.7
Change-Id: I69c8cfe4e2d6d7d4659edda621ba1afe9768035b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
This avoids added resources:
":/qpdf/qpdfa_metadata.xml"
":/qpdf/sRGB2014.icc"
Pick-to: 6.7
Change-Id: I89a130bd281c5550f1c3dcead8336e0c3de6bc84
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This reverts commit c41733b06b.
Based on the Grafana data, last flaky was August 14, 2023, and
the test works fine on local vm with stressed cpu.
Fixes: QTBUG-115598
Pick-to: 6.7 6.6 6.5
Change-Id: I634598d20a581d4d1443a3fd81e1e9481bfa2545
Reviewed-by: Inho Lee <inho.lee@qt.io>
Fix the amiguity in the comparison of a QByteArray and a char*
Task-number: QTBUG-117661
Change-Id: Ic5142b7bc2a8220d244312414618028e8cc50d09
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Clang supports `__attribute__((fallthrough))`. While C++ sources use
[[attribute]], the C codepath still requires a fallback.
Pick-to: 6.7
Change-Id: Iaa93d2debc21fdd34e414ddb024b95942ae9191f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It was added in commit 75a2c81b0041df4ca59178cf52d9e5a8815f3524:
Handle posix_spawn using exit code 127 to indicate fail-to-start
Most posix_spawn implementations are done using fork(), so the only way
to report errors afer fork() is via a special exit code.
Support for posix_spawn was removed when we dropped QNX 6.5 support in
Qt 5.7 (commit 005a8bfbf0). Also
complements commit d012e953bf.
Pick-to: 6.6 6.7
Change-Id: I76ffba14ece04f24b43efffd17aadead7c30146b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
QAFE sub-classes endEntryList() overrides returned nullptr, which is
exactly what the base class implementation does.
Change-Id: I2e901647cd087c3b8ba674db6e7b371e620af340
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... when it's first assigned, instead of in currentFilePath(), muck like
what QFileSystemIterator does.
Change-Id: Id58ddcd6df5ad911fd5a62f1ca386e25626cb781
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- This is private API, no point having the d-pointer indirection; store
the members in QAbstractFileEngineIterator directly. In subsequent
commits sub-classes can use m_fileInfo from the base class, saving
some space in e.g. QFSFileEngineIterator
- Make setPath() public, it's a setter called by some QAFEI sub-classes
- Remove EntryInfoType enum, nothing uses it
This is a step towards remodeling QAFEIterator, and its subclasses,
after QFileSystemIterator, i.e. adding a `virtual bool advance()`
method, and dropping next()/hasNext(). This also is more inline with the
QDirListing class (which uses STL-style iterators).
Change-Id: I8ad774b854231e3cdce4935f04c8bf24031001dd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
De-duplicates the code between the two classes.
[ChangeLog][Core][QDirIterator] This class has been deprecated and may
be removed in a future Qt release. Use QDirListing instead.
Change-Id: Iceba5091e72ea462dc9c5145a474bf312ee78043
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Which will be used to represent timer IDs. Thanks to Marc for the idea
to use "a strongly typed int".
QTimer got a new id() method that returns Qt::TimerId (can't overload
timerId()). Various classes in qtbase have a member named timerId(), but
a new method is needed anyway in QTimer so id() it is (this is the
reason QChronoTimer only has id() and no timerId()). Besides
timer.timerId() has an extra "timer".
This commit fixes the inconsistency between QObject using `0` timer id
to indicate "failed to start", while QTimer::timerId() returned `-1` to
indicate "timer is inactive". QTimer::id(), being a new method and all,
now returns Qt::TimerId::Invalid, which has value `0`, so that the
values match between the two classes. Extend the unittests to ensure
QTimer::timerId()'s behavior is preserved.
[ChangeLog][Core][QObject] Added Qt::TimerId enum class, that is used to
represent timer IDs.
Change-Id: I0e8564c1461884106d8a797cc980a669035d480a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Q{Chrono}Timer::isActive() has to use isActiveData so that the bindable
property is correctly queried. However in other places in the code we
can take a shortcut by checking id > 0.
So rename QTimerPrivate::isActiveActualCalculation() to make it more
palatable and use it throughout the code.
Change-Id: I3378233e553fd860d9f105bba013dc9ffc31a2ba
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The interval in QTimer is a QProperty of type int, which means it's
limited to the number of milliseconds that would fit in an int (~24
days), this could cause overflow if a user constructs a QTimer with an
interval > INT_MAX milliseconds. And it can't be easily changed to use
qint64/std::chrono::nanoseconds:
- changing the getters to return qint64 means user code would have
narrowing conversions
- the bindable QProperty interval can't be changed to qint64 during
Qt6's lifetime without the risk of breaking user code
- adding a new bindable QProperty that is qint64/nanoseconds is an
option, but it has the complication of what to do with the int
interval; set it when setInterval(milliseconds) is used by using
saturation arithmetic? and what about notifying observers of the
changed interval?
Thus the idea of creating a new stop-gap class, QChronoTimer, as a
cleaner solution. Both classes use QTimerPrivate.
During the lifetime of Qt6, QTimer's interval range is about 24 days,
whereas QChronoTimer's interval range is about 292 years
(duration_cast<years>nanoseconds::max()).
Currently the plan is to fold QChronotTimer back into QTimer in Qt7.
Mark all QPropertyS in the new class as FINAL since they aren't
intended to be overridden; this offers a performance boost for QML[1].
[1] https://lists.qt-project.org/pipermail/development/2024-February/044977.html
[ChangeLog][QtCore] Added QChronoTimer, which uses a
std::chrono::nanoseconds intervals, as a replacement for QTimer.
Fixes: QTBUG-113544
Change-Id: I71697f4a8b35452c6b5604b1322ee7f0b4453f04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Ultimately this is the best way to keep the log history of the code.
Change-Id: I3413deffdb093a3239d65b6ca939e744224e722a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Regression after 9e78256579.
Apparently the string based connection syntax is more lenient,
as with PMF-style connects, we (correctly) get:
ASSERT failure in QWindowContainer: "Called object is not of the
correct type (class destructor may have already run)"
when the QWidget destructor closes the QWindow and we get a
synchronous callback from the platform that we've lost the
focus window.
Pick-to: 6.7
Change-Id: I8f25b3b050e11913ec0f0941eaf831c88b4249f9
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Use QDirListing in the Bootstrap build instead of QDirIterator.
Drive-by changes:
- more const variables
- use emplace_back() instead of append() where appropriate
Change-Id: Ie1f0d03856e557c4bfabfff38a87edc7da86d091
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Then we will automatically handle invalid leading characters instead
of throwing away the whole sequence when it cannot be converted.
Added a test that was failing before.
Drive-by change: add a comment explaining why we
have the stack allocated buffer.
Task-number: QTBUG-118834
Change-Id: I647a58f2ba95e2e7ed4ea6a964d99ecc0c91fad3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Some machine in CI is failing some of these sometimes and
I would like to know by how much.
Pick-to: 6.7
Change-Id: I88b41d5cde81419f7c11f7038101962630eb31ef
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The current logic that we will disable the read notification if we
have any data at all doesn't make sense for users who use the
receiveDatagram functionality, since they will not make any calls
that trigger the read notifier to be re-enabled unless there is a
datagram ready for us to hand back.
Fixes: QTBUG-105871
Pick-to: 6.7 6.6 6.5
Change-Id: I0a1f1f8babb037d923d1124c2603b1cb466cfe18
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QDomText::splitText() needs to unref() the newly created QDomText
instance as it does not use it by itself
Pick-to: 6.7 6.6 6.5 6.2 5.15
Fixes: QTBUG-40561
Change-Id: I593011b63c39f2310204d97ec61da7cf78a0fc14
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>