The method is only called in two places: observerProperty (which only
takes care of calling unlink, too, if necessary) and in
registerWithCurrentlyEvaluatingBinding_helper. In the first case, the
method most likely gets inlined anyway. In the latter case, we really
want to avoid the overhead of an additional function call to speed up
registration of the property with the binding. Considering that it is an
internal method, there is no need to worry about code explosion.
Pick-to: 6.2
Change-Id: I3f0f0e37108f3859321d3b432e37fc8da3c15dc0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This avoids another round of TLS lookups in evaluateRecursive when we
construct the BindingEvaluationState.
Pick-to: 6.2
Change-Id: Icfa9fd81fc6f54623d384c4d3fce33f4d4d549b9
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
- Ensure that the allocateDependencyObserver fast path is inlined.
- Use addObserver instead of observerProperty; we know that a freshly
allocated observer does not have its prev pointer set. If prev weren't
a private member, we could simply use Q_ASSUME(ptr->prev == nullptr),
but making it public or befriending the class seems like a bad idea,
as it grants too much access to the internals.
Pick-to: 6.2
Change-Id: Ia845f2807c70512563f7b9e1ecb85fe82b66208c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
If we have no currentBinding, then registerWithCurrentlyEvaluatingBinding
will not do anything. Thus we can completely avoid fetching the storage.
Pick-to: 6.2
Change-Id: Ic20142e4c4e09752b5c41b959f66080e6885e6c3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
By putting the groupUpdateData pointer into the same thread local as the
binding status, we avoid having to fetch two thread_local variables.
Moreover, we can reuse the caching mechanism which we have in place for
QBindingStatus to avoid costly TLS lookups.
Pick-to: 6.2
Change-Id: Iaea515763510daab83f89b8e74f35a80965d6965
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
If the QBindingStatus we receive from the QObject is from the thread
which is currently running, we do not need to refetch the thread local;
the reason we refetched the thread_local was after all only to guard
against the case where a QObject's property gets read in a different
thread.
To determine whether we are in the same thread, we can store the thread
id in the thread_local structure. Currently, it only gets initialized
for the main thread in QCoreApplication (as bindings are mostly used
there).
At a later point, we could either expose initBindingStatusThreadId, or
call the function when a QThread gets started.
Pick-to: 6.2
Change-Id: Id8eb803973bb083abfab83a62bfccc9e88a4e542
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We try our best to pass on the file location of a failure, including for
fatal errors, but the reporting or logging machinery should not assume
there is one.
By passing on nullptr for the file location we allow the logging backends
to decide how to handle the situation, e.g. by not emitting extra fields
for failure location.
This effectively reverts c25687fa0b,
in favor of relying on the backends to cope with null filename,
which they already did.
As qFatal uses QMessageLogger, which by default disables file/line
information in release builds, we need to explicitly enable this in
our self-tests, to get uniform test results. Similarly, we disable
file/line info from testlib itself, as reporting Qt internal file
and line information for user diagnostics is less useful. The odd
one out there is qtestdata.cpp, which still ends up in test output
due to using QTEST_ASSERT instead of qFatal for its diagnostics.
Cleaning up that, and unifying how we report testlib issues to the
user, is left for another day.
Pick-to: 6.2
Change-Id: Ib9451b8eed86fe3ade4a4dcaf0037e1a3450321c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QtTest best practices documentations recommends using output
mechanisms such as qDebug() and qWarning() for diagnostic messages,
and this is also what most of our own tests do.
The QWARN() macro and corresponding internal QTest::qWarn() function
was added when QtTest was first implemented, but was likely meant as
an internal implementation detail, like its cousin QTestLog::info(),
which does not have any corresponding macro.
This theory is backed by our own QtTest self-test (tst_silent)
describing the output from QWARN() as "an internal testlib warning".
The only difference between QWARN() and qWarning(), besides the much
richer feature set of the latter, is that qWarning() will not pass
on file and line number information in release mode, but QWARN() will.
This is an acceptable loss of functionality, considering that the user
can override this behavior by defining QT_MESSAGELOGCONTEXT.
[ChangeLog][QtTest] QWARN() has been deprecated in favor of qWarning()
Pick-to: 6.2
Change-Id: I5a2431ce48c47392244560dd520953b9fc735c85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This function is called by qt_add_executable. There is no need to
expose it as public function.
Fixes: QTBUG-95172
Change-Id: I85a1d906ecda42458e226db225e47c1d348a72f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This change introduces new behavior to error out when configuring user
projects if the CMake version used is too old for Qt to work with.
The main motivator is the requirement of new CMake features to ensure
object libraries are placed in the proper place on the link line in
static builds.
The minimum CMake version is computed based on whether Qt was
configured as shared or static libraries.
At the moment the required versions for building and using Qt are the
same.
The minimum versions are defined in qtbase/.cmake.conf in the
following variables
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_SHARED
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_STATIC
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_SHARED
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_STATIC
Qt Packagers can disable the version check when configuring Qt
by setting
QT_FORCE_MIN_CMAKE_VERSION_FOR_BUILDING_QT and
QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT.
In this case it is the packagers responsibility to ensure such a Qt
works correctly with the specified CMake version.
User projects can also set QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT
to disable the version check. Then it's the project's developer
responsibility to ensure such a Qt works correctly.
No official support is provided for these cases.
Implementation notes.
The versions required to build Qt are stored in
QtBuildInternalsExtra.cmake
whereas the versions required to use Qt are stored in a new
QtConfigExtras.cmake.
Also the policy range variables stored in
QtBuildInternalsExtra.cmake are now regular variables instead of cache
variables, to properly allow overrides per-repository.
Some renaming of functions and variables was done for a bit more
clarity and easier grep-ability.
Pick-to: 6.2
Task-number: QTBUG-95018
Change-Id: I4279f2e10b6d3977319237ba21e2f4ed676aa48b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Building a static library Qt configuration will now require a
minimum CMake version of 3.20.
Qt builders and packagers can still opt out of the mentioned minimum
required version by configuring Qt with QT_FORCE_MIN_CMAKE_VERSION.
Such a Qt configuration is /NOT SUPPORTED/.
To facilitate these changes, the minimum version check has been moved
to happen after the BUILD_SHARED_LIBS option is computed by either
QtAutoDetect.cmake or set by a user provided cmake toolchain file.
Introduce a new QT_MIN_SUPPORTED_CMAKE_VERSION_FOR_STATIC_QT variable
in .cmake.conf to mark the minimum version for a static Qt build.
Pick-to: 6.2
Task-number: QTBUG-95018
Change-Id: Idc1875729f26a7c635b6bd26ac0c1be973917c13
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
In order to filter out file names based on the user's settings,
QFileSystemModel used to have a loop that tested if a given file
name matched one of the filters. The problem is that each filter
(a wildcard) was converted to a QRegularExpression _inside_ the loop.
This causes a quadratic behavior (number of files * number of filters).
Instead, build the regexps once when the filters are set (or the case
sensitivity is changed, as that affects the filtering), and simply
_use_ them in the loop.
Simplify and correct some related code as a drive by.
Done-with: Jean-Michaël Celerier
Fixes: QTBUG-95383
Pick-to: 6.2 6.1 5.15
Change-Id: I6bc336364c145bb05793a8f867545d7715d35832
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The port from hand-rolled function storage to std::function
inadvertently removed the helper variable of static storage duration
whose dtor would unregister the conversion function. This caused
QTBUG-94831, where the cleanup of conversion functions attempts to
call code (via std::function) from a library that has already been
unloaded.
Restore the 5.15 behavior by adding a static-storage-duration scope
guard to unregister the conversion and view functions from Qt upon
library unload (when static objects are destroyed). Unlike 5.15, only
install the scope guard upon successful registration, ensuring that
only the DLL which successfully registered its conversion function
unregisters it again.
Amends 0e4ae4fbf8.
Add some strategic std::move()s as a drive-by.
Pick-to: 6.2
Task-number: QTBUG-94831
Change-Id: I391ca667420cf0d98a166676b9bb363d6e190306
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of contains(), 1-2x operator[](), and remove(), equalling 3-4
separate lookups, use find() + erase(), which does just one
lookup.
Since our erase() function is C++11-compliant these days and takes
const_iterator instead of (mutable) iterator, we can use the const
find() overload to delay a detach (attempt) until we actually erase().
Change-Id: I8e67a48e221e548528049fa093ab7ef2f1802f7e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Move the documentation of the format and precision parameters to
QLocale::toString(double, char, int), reference it from various
QString methods (instead of repeating there and referencing one of
those from QLocale). Add brief first lines for various documentation
comments.
Mention the special handling of negative precision in the moved
documentation. Mention QLocale::FloatingPointShortest, add its type to
\sa lines of methods it affects. Change a comment on some code
implementing its special treatment to make clear that it does apply to
'e' and 'f' formats, not only to 'g', even though it has no overt
special handling in that code; and update docs to report the
undocumented behavior the comment previously described.
Document how infinity and NaN are represented. Be somewhat more
consistent about single-quoting the format names where referred to and
applying \c to character constants.
Make clear what things are different between different methods using
these parameters. Reference QString::number() from QByteArray's
relevant methods, since they share its quirks.
In the process, rename the format and precision parameters of relevant
functions so they're consistently named, replacing a mixture of
abbreviated forms.
Pick-to: 6.2
Change-Id: I077521b30346000e4b4f6968a8e750e934f72937
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Because we're using a thread-specific global static, we need to recreate
the QCollator type every time setDefault() is called. Since one is
stored per-thread, we simply increment a generational counter and check
that the next time that QString::localeAwareCompare is called in each
thread.
The issue was introduced on f6425da424
(5.12) even though we were supposed to be using QCollator since commit
5279134935 (5.3).
Fixes: QTBUG-95050
Pick-to: 6.2
Change-Id: I7e0b82c2d2fe464082d8fffd1696a8c9f74e5b30
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
USE_COMPARESTRINGEX is not defined anywhere. Its definition was removed
by commit 45b0f1be68 ("Remove winrt").
Change-Id: I7e0b82c2d2fe464082d8fffd1696a931fa301986
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This follows up on commit 98666c8afc,
which did the same for QString. If someone wants to get formatting
suitable to an unsigned value, they can cast the value to that
unsigned type and the correct overload shall pick it up.
[ChangeLog][Important Behavior Changes] QByteArray's formatting of
negative whole numbers to bases other than ten now, like QString's
(since Qt 6.0), formats the absolute value and prepends a minus sign.
Task-number: QTBUG-53706
Pick-to: 6.2
Change-Id: I91fee23d25ac0d5d5bcfcbeccbac1386627c004a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use _qt_internal_set_up_static_runtime_library() to set correct MSVC
runtime library for targets created by qt_add_executable(),
qt_add_library(), qt_add_plugin() and qt_add_big_resources(), to bring
convenience to user projects.
Pick-to: 6.2
Change-Id: Ia49f1e90989c464820824be3e1eef3df1351cdcf
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This amends 3224c6d7d1 to account for the
case when the dockwidget is already floating.
Task-number: QTBUG-70137
Pick-to: 6.2 6.1 5.15
Change-Id: If8b345565b11b44beb3fb4b697cfe812c29c6396
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
One is a bad application or library in this case, but nonetheless
we should handle this more gracefully then just crashing due to
the QRhi already having been destroyed. Mainly because in Qt 5 one
could get away with the same: releasing OpenGL objects underneath,
for example, a QSGPlainTexture with no (or wrong) GL context did
not generate any user visible fatal errors. So we should not crash
in Qt 6 either with these code bases.
In debug builds or when QT_RHI_LEAK_CHECK is set, one will get the
unreleased resources warning printed in Qt 6, which is a step
forward compared to Qt 5. So there is still some indication that
something is badly designed, even if the application survives.
Task-number: QTBUG-95394
Pick-to: 6.2
Change-Id: I944f4f425ff126e7363a82aff926b280ccf1dfc3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The value returned from shouldHaveNonClientDpiScaling()
controls two related behaviors:
1) Should Qt call user32dll.enableNonClientDpiScaling()
2) Should Qt code treat NonClientAreaScaling as enabled.
Commit c35643db updated shouldHaveNonClientDpiScaling()
to account for the fact that PerMonitorV2 always enables
NonCLientAreaScaling, with the intent to disable 1)
However this also disables 2), which was not intended.
Instead, make shouldHaveNonClientDpiScaling() always
return true when PerMonitorV2 is enabled, and then also
omit calling the user32dll API in this case.
Change-Id: I1d06f36a3d06becc667351fadcb00ab28af6ec4b
Pick-to: 6.2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
We were using CGDisplay callbacks to determine when a screen reconfiguration
had happened, and when it had propagated to changes in NSScreen.screens,
so that we could update our QScreen view of the world.
Unfortunately the CGDisplay callbacks were not deterministic enough to
use as a signal for when a reconfigure had completed.
Since we can't rely on NSApplicationDidChangeScreenParametersNotification
either (it comes in too late), we're now resorting to updating our QScreens
at every chance we get:
- On every CGDisplay reconfiguration ending
- On QCocoaWindow::windowDidChangeScreen() as a result of AppKit
moving the window.
- On NSApplicationDidChangeScreenParametersNotification
- On QCocoaScreen::get() as a last resort
Since the result of these updates are only reflected as QScreen property
updates or QGuiApplication signals if a change actually occurred, it should
be safe to update early and often.
Task-number: QTBUG-77656
Fixes: QTBUG-80193
Pick-to: 6.2 6.1 5.15
Change-Id: I98334a66767736d94ad2fcb169e65f0d8bc71a30
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Currently number(double) creates a QByteArray-instance and calls
setNum(double).
setNum(double) creates a QByteArray-instance and copy-assigns it to
itself.
By making setNum(double) call number(double) we can cut one creation
from numbers(double)'s path, and making setNum no worse than it was.
The other pairs of setNum/number are left alone as they don't have this
issue.
Change-Id: Ib611ebc78db64f74244a56cb8e384e42bc7d1758
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Also change the timer default value to use QDeadlineTimer::Forever.
Pick-to: 6.2
Change-Id: Ia6d0101872a5d01b04e146cd9b2f90315cb8eb2e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The actual buffering is performed either in the inner socket (Unix),
or in the pipeReader (Windows). To avoid unnecessary copying of data
between buffers, enforce unbuffered mode for all implementations,
which slightly improves read performance.
Change-Id: Idb2a09f35823b9945c71231710290be12d9930f7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
For subclasses that implement alternative buffering (such as
QLocalSocket), it would be useful to bypass the QIODevice's internal
buffer, even if the QIODeviceBase::Unbuffered flag is not set when
opened.
By setting the readBufferChunkSize member to 0 in their constructors,
these classes now unconditionally switch the base class to unbuffered
mode, while still reporting buffering with openMode() function.
Change-Id: I351bc57ac0ccb45c81f8c6be15f1745131aa26ba
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
It would have been nice to ensure that a device is registered already in
mouseEnteredImpl(); but in that context, NSEvent.deviceID is always 0,
and we can't find out anything else about the device.
QWindowSystemInterface::handleEnterEvent() doesn't currently take a
QPointingDevice either.
In handleMouseEvent() and scrollWheel(), deviceID seems unique for each
trackpad or Magic Mouse, but 0 for any plain USB mouse. There, the first
mouse that the user interacts with becomes primaryPointingDevice():
its deviceID is assigned to systemID (except if deviceID == 0, we use
1 instead, to avoid the auto-incrementing device ID assignment in the
QInputDevicePrivate ctor.) When scrolling occurs, we update the
capabilities to have PixelScroll if theEvent.hasPreciseScrollingDeltas.
So over time, QInputDevice::devices() should build up to a complete
list, with capabilities() also distinguishing plain mice from those that
have the PixelScroll capability. And in the common case that the user
has only one Apple pointing device, it becomes primaryPointingDevice().
Pick-to: 6.2
Task-number: QTBUG-46412
Task-number: QTBUG-63363
Task-number: QTBUG-72167
Change-Id: Id9771b4dfd765e49023bd57d42a2aa4d0635a3b2
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The key part of FailureReportingMode::QtTest is that it will result
in a test failure (via QTest::qVerify); not that it's using the
QtTest logging machinery.
Pick-to: 6.2
Change-Id: I18472fba173ce1323748f1f87301a4defa87020e
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
- avoid calls to private and virtual functions, if the device is not
open;
- avoid repetitive checks in loops;
- add missing checks in readLine() overloads;
- remove check against unsuccessful resize().
Change-Id: I973d5931163b25db1c09c7c3b66f29ea90bb1b29
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This signal is emitted by the QIODevice itself, so we don't have to
forward it from the internal socket.
Pick-to: 6.1 6.2
Change-Id: I85745f36d7a27d92f339a9184de3b6e5d46f6f34
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Remove the QString/QStringView/QLatin1String/const char* overloads
from the API, but not the ABI.
As a drive-by, replace a use of QStringView::left() by truncate(), as
suggested by a comment.
[ChangeLog][QtCore][QUuid] The from-string constructor and the
fromString() function now take QAnyStringView (was: overload set with
a subset of QString, QByteArray, const char*, QLatin1String,
QStringView each).
Change-Id: If7fa26cfbef9280480c78b669d9f5f14118995ed
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Apart from a more fitting, minimal, API, QDuplicateTracker also
transparently uses C++17 pmr::monotonic_buffer_resource to avoid, or
at least reduce, memory allocations.
Change-Id: I155f5518190c5f8f6d21fbec3fcecd6bcc7ff852
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
From the API review session, a potential deadlock behavior might
occur when using QFuture's synchronous APIs on the UI thread. Also
the fact that this api currently have an implementation only for
Android. For those reasons we thought this API could be postponed
until Qt 6.3, when the QFuture concern is addressed and other
platforms other than Android are implemented as well.
Pick-to: 6.2
Change-Id: I1aef025488c24791da85d15fb57367d3e5e681be
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The comment indicates how to use QT_BUILD_REMOVED_API, which includes
a #include of qglobal.h; but we have a tool, run somewhere in
configure, that grumbles about this #include (unaware, I suspect, that
it's in a comment), saying we should #include <QtCore/qglobal.h>; so
change the comment to say that. Presumably this is our recommended way
to do includes, so we should follow it when suggesting how to write
code.
This amends commit 0c8b98774c.
Change-Id: I4683ad6f1c0eedec3eaa02ac40c5d017059a49b0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Formatting using scientific notation with extra precision wasn't tested
Change-Id: I7a89a0f3d6468515604e43e52fc366dedf3c39ea
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
According to Microsoft Docs [1], DWM composition is always
enabled and can't be disabled since Windows 8. Now that
we are cleaning up pre-Windows 10 code, this apparently
needs to be removed as well.
[1] https://docs.microsoft.com/en-us/windows/win32/api/dwmapi/nf-dwmapi-dwmiscompositionenabled
Task-number: QTBUG-84432
Change-Id: I64dc049e0741600c8d0ae4db0e9e3bc98a211339
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
The format was renamed in 27db9e458c.
Pick-to: 6.2
Change-Id: I53975c7467d8768dc9dc9ac2d89c42eefa12e22f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
For historical reasons a few of the subtests are skipped when
running with anything but the plain text logger to stdout.
To ensure we have as broad test coverage as possible for the
expected output of the various loggers we run these tests in
stdout-mode.
Pick-to: 6.2
Change-Id: I856905d1543afe89710533657a55bd599c0305fd
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
If Vulkan headers are present on the system when qtbase is configured,
QtGui and QtOpenGL should be compiled with Vulkan support.
If a user project uses a Qt built with Vulkan support, but their system
is missing Vulkan headers, the project configuration needs to succeed.
The project will get compilation errors if it uses Vulkan headers, but
that's intended.
This use case was broken when fixing Vulkan to be found when building
Qt for Android.
Fix the regression with a combination of things
1) Mark the WrapVulkanHeaders package as optional (already the case)
2) Use the include directories directly when compiling Gui and OpenGL
3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to
consumers only if the target exists. It won't exist if Vulkan
include dirs are not found
This also requires some changes in pri and prl file generation.
For prl file generation, we don't want to link to the
WrapVulkanHeaders target, so we filter out all dependencies that
use TARGET_NAME_IF_EXISTS for anything that calls
__qt_internal_walk_libs which includes qt_collect_libs.
For pri files, we make sure to generate a uses=vulkan/nolink clause
by inspecting a new _qt_is_nolink_target property on the target.
We also don't add include dirs to the pri file if the new
_qt_skip_include_dir_for_pri property is set.
This is intended for Vulkan, because there is separate qmake logic to
try and find the include dirs when configuring a user project.
As a drive-by, fix nolink handling for WrapOpenSSLHeaders.
Amends bb25536a3d
Amends 7b9904849f
Pick-to: 6.2
Fixes: QTBUG-95391
Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This fixes building Qt with Vulkan support on macOS which aside from
the regular Vulkan headers also needs the location of the MoltenVK
headers.
This assumes the usage of the LunarG Vulkan SDK for macOS.
Pick-to: 6.2
Fixes: QTBUG-80576
Change-Id: I030b2fdeaafdd7bf5ebe6fb4c9ea860917e84056
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The JUnit reporter was initially named xunit, but the naming was inaccurate
and the reporter was renamed in 27db9e458c.
The corresponding test has now been renamed as well, and as an added bonus
we only run it for that reporter.
Pick-to: 6.2
Change-Id: I59cb7d949514cdf46a0199a53a7a3e39f833207c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
