This marks the end of EGL and OpenGL ES support on Windows.
The concepts of -opengl dynamic, -opengl desktop, QT_OPENGL=software,
etc. remain unchanged, with the exception of the disapperance of
everything ANGLE related.
CMake builds now work identically to qmake on Windows: they default to
'dynamic' OpenGL on Windows, unless -DINPUT_opengl=desktop is specified.
On Windows, Qt 6 is expected to default to the "dynamic" OpenGL model by
default, just like Qt 5.15. This can be changed by switching to "desktop"
OpenGL, which will link to opengl32 (publicly, so other libs and applications
will do so as well) and disallows using another OpenGL DLL.
The "dynamic" mode is essential still because the fallback to a software
rasterizer, such as the opengl32sw.dll we ship with the Qt packages,
has to to work exactly like in Qt 5, the removal of ANGLE does not
change this concept in any way (except of course that the middle option
of using ANGLE is now gone)
When it comes to the windows plugin's OpenGL blacklist feature, it works
like before and accepts the ANGLE/D3D related keywords. They will
then be ignored. Similarly, requesting QT_OPENGL=angle is ignored (but
will show a warning).
The D3D11 and DXGI configure time tests are removed: Qt 5.14 already
depends on D3D 11.1 and DXGI 1.3 headers being available unconditionally
on Win32 (in QRhi's D3D11 backend). No need to test for these.
[ChangeLog][Windows] ANGLE is no longer included with Qt. Dynamic OpenGL
builds work like before but ANGLE is no longer an option. OpenGL proper
or an alternative opengl32 implementation are the two remaining options
now. Attempting to set QT_OPENGL=angle or Qt::AA_UseOpenGLES will have
no effect on Windows.
Fixes: QTBUG-79103
Change-Id: Ia404e0d07f3fe191b27434d863c81180112ecb3b
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Make sure that, if Qt was configured with -debug-and-release, winmain
and user apps are generated by default in debug-and-release mode, too.
This amends 9b4ec1393f .
Change-Id: I0f169d63ca98c9bde41114225004a0844425db33
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The requirement to separate debug and release DLLs on Windows stems from
the Visual Studio C run-time library appearing in two different variants
(debug and release) and not mixing well. It's possible to perform builds
without optimzations and with debug symbols while linking against the
release version of the C run-time, but at the same time the debug
version of the run-time brings other developer visible advantages.
MinGW on the other hand does not have this distinction, does not ship
with separate DLLS and does also not require the VS C runtime library.
Therefore we do not need this separation for MinGW, which means that our
packages can be reduced in size and application developers wishing to
debug their applications do not have to use debug builds of the Qt
libraries or run into Qt internal debug code.
Task-number: QTBUG-78445
Change-Id: Idf588606091298dc44262c4c89e689df18d34747
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Some distributions do not define MINGW_HAS_SECURE_API globally,
resulting in methods like wgetenv_s not being declared in the
headers.
This is probably to keep compatibility with Windows XP. Anyhow,
we don't support Windows XP anymore, so we can safely add the
define.
Note that this is not necessary for the mingw-builds distro,
which is the only one we test and support. Anyhow, I don't
see any risk in adding these for other distributions.
Diff was provided by Philippe Dunski in the bug report.
Task-number: QTBUG-67443
Change-Id: I3a64b11541fe95e527ed44bbf8ad94469d457d3d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
