Test each include file directly, instead of doing a large #include. This
verifies that each header is compilable on its own. One big advantage of
doing it via a special compiler in qmake is that we skip pre-compiled
headers, which has hidden build errors in the past.
This solution is implemented by making syncqt produce a second list of
headers. This list is the same as the list of headers in the source
code to be installed, minus the headers that declare themselves to be
unclean, via the pragma:
#pragma qt_sync_skip_header_check
This mechanism is applied only for public libraries (skipping
QtPlatformSupport, an internal_module).
This test is enabled only for -developer-builds of Qt because it
increases the compilation time.
On QtTest: the library only links to QtCore, but it has two headers that
provide inline-only functionality by including QtGui and QtWidgets
headers (namely, qtest_gui.h and qtest_widget.h). If those two modules
aren't getting compiled due to -no-gui or -no-widgets to configure, we
need to remove the respective headers from the list of headers to be
checked. If they are being built, then we need to make QtTest's build
wait for the headers to be generated and that happens when qmake is
first run inside the src/gui and src/widgets directories.
Change-Id: I57d64bd697a92367c8464c073a42e4d142a9a15f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
And thus do not disable warnings for the whole module when
configured with -qt-freetype.
Change-Id: I601a7c2990c8e3377531a28078db73800c138ec1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
We already have an infrastructure for that.
Change-Id: I9110b74dcf7f93362586687da6f112e72cb663a4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The dependency was introduced with change 8b0fcd87
Change-Id: I9b5eb3d30c30676313e65916f905f76596670260
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
the qt headers live in the source dir in this configuration.
instead of hard-coding the path in the project file, use the correct
module variable. this requires harfbuzz-ng to be built after corelib.
Change-Id: If1b64b59a0939d3b5190331fcf70da566d4eeedd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Platformsupport doesn't need network in order to compile and link.
Change-Id: Ifda2db9c39d89619ff21cbcd21dc5bf97fe58f55
Reviewed-by: Jørgen Lind <jorgen.lind@theqtcompany.com>
The dynamic builds (-opengl dynamic) are now functional on Windows.
In such a build no components in Qt link to any OpenGL libraries directly
and qmake will not automatically add any such libraries to the
applications' makefiles. Instead, the libraries are chosen and loaded
during runtime and applications are expected to use QOpenGLFunctions
instead of direct OpenGLfunction calls.
Set the environment variable QT_OPENGL to desktop or angle to skip testing
and force the given implementation. The application attributes (AA_UseOpenGLES
and such) are also taken into account.
The testing logic is same as before: We try to load opengl32 and
resolve a shader related function. If this fails, ANGLE is chosen. This
allows utilizing full desktop OpenGL on systems that have proper drivers,
while a transparent fallback to ANGLE will be done automatically for
systems that don't. The latter includes also remote desktop connections.
Software rendering via Mesa llvmpipe is supported too. The fallback is
automatic on systems where the desktop test fails and ANGLE fails to load
or initialize (e.g. due to missing libs like d3dcompiler), as long as a
suitable patched build of Mesa is available.
[ChangeLog][QtGui] Dynamic OpenGL implementation loading is now supported
on Windows. This requires Qt to be configured with -opengl dynamic.
Task-number: QTBUG-36483
Change-Id: Ie8bb25a6d55b3a1609b00150aeccd909aec27313
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
For now only xcb on GLX is supported. Other platforms will follow later.
Add also some missing documentation for the platform OpenGL context factory
functions.
[ChangeLog] QOpenGLContext is now able to adopt existing native contexts.
Task-number: QTBUG-37552
Change-Id: I5dd959f102df178f646b2df5989203b5dc6de376
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
Migrating this is out of scope for the time being.
Change-Id: Iac4a98d8db8e132a6ffa28075548fe2af76637fc
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Being a part of QtGui, HarfBuzz-NG breaks build with -Werror.
Instead of disabling a particular warnings-as-errors,
build a prefixed static library and make it a link-time dependency.
Change-Id: Id0be1f0e0034092d50f83cd364d5c65940fee869
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
The patch introduces a new build configuration on Windows which
can be requested by passing -opengl dynamic to configure.
Platforms other than Windows (including WinRT) are not affected.
The existing Angle and desktop configurations are not affected.
These continue to function as before and Angle remains the default.
In the future, when all modules have added support for the dynamic
path, as described below, the default configuration could be changed
to be the dynamic one. This would allow providing a single set of
binaries in the official builds instead of the current two.
When requesting dynamic GL, Angle is built but QT_OPENGL_ES[_2] are
never defined. Instead, the code path that has traditionally been
desktop GL only becomes the dynamic path that has to do runtime
checks. Qt modules and applications are not linked to opengl32.dll or
libegl/glesv2.dll in this case. Instead, QtGui exports all necessary
egl/egl/gl functions which will, under the hood, forward all requests
to a dynamically loaded EGL/WGL/GL implementation.
Porting guide (better said, changes needed to prepare your code to
work with dynamic GL builds when the fallback to Angle is utilized):
1. In !QT_OPENGL_ES[_2] code branches use QOpenGLFunctions::isES() to
differentiate between desktop and ES where needed. Keep in mind that
it is the desktop GL header (plus qopenglext.h) that is included,
not the GLES one.
QtGui's proxy will handle some differences, for example calling
glClearDepth will route to glClearDepthf when needed. The built-in
eglGetProcAddress is able to retrieve pointers for standard GLES2
functions too so code resolving OpenGL 2 functions will function
in any case.
2. QT_CONFIG will contain "opengl" and "dynamicgl" in dynamic builds,
but never "angle" or "opengles2".
3. The preprocessor define QT_OPENGL_DYNAMIC is also available in
dynamic builds. The usage of this is strongly discouraged and should
not be needed anywhere except for QtGui and the platform plugin.
4. Code in need of the library handle can use
QOpenGLFunctions::platformGLHandle().
The decision on which library to load is currently based on a simple
test that creates a dummy window/context and tries to resolve an
OpenGL 2 function. If this fails, it goes for Angle. This seems to work
well on Win7 PCs for example that do not have proper graphics drivers
providing OpenGL installed but are D3D9 capable using the default drivers.
Setting QT_OPENGL to desktop or angle skips the test and forces
usage of the given GL. There are also two new application attributes
that could be used for the same purpose.
If Angle is requested but the libraries are not present, desktop is
tried. If desktop is requested, or if angle is requested but nothing
works, the EGL/WGL functions will still be callable but will return 0.
This conveniently means that eglInitialize() and such will report a failure.
Debug messages can be enabled by setting QT_OPENGLPROXY_DEBUG. This will
tell which implementation is chosen.
The textures example application is ported to OpenGL 2, the GL 1
code path is removed.
[ChangeLog][QtGui] Qt builds on Windows can now be configured for
dynamic loading of the OpenGL implementation. This can be requested
by passing -opengl dynamic to configure. In this mode no modules will
link to opengl32.dll or Angle's libegl/libglesv2. Instead, QtGui will
dynamically choose between desktop and Angle during the first GL/EGL/WGL
call. This allows deploying applications with a single set of Qt libraries
with the ability of transparently falling back to Angle in case the
opengl32.dll is not suitable, due to missing graphics drivers for example.
Task-number: QTBUG-36483
Change-Id: I716fdebbf60b355b7d9ef57d1e069eef366b4ab9
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
d3dcompiler_qt is a DLL for use with ANGLE which replaces d3dcompiler_XX
at runtime to proxy shader compilation calls. This is useful for:
- Loading the newest D3D compiler DLL found, instead of loading the
version specified when Qt was compiled
- Reporting better debug information when the compiler cannot be loaded
- Caching shader blobs for later use
- Returning cached shader blobs
- Deferring compilation to another mechanism, such as a D3D compilation
service running on a host debugging machine *
The above use cases are especially important for Windows Store apps, as
they are not allowed to ship the d3dcompiler. On Windows Phone, where
there is no runtime compiler, this is essential for handling QtQuick apps
which require runtime shader compilation.
* This requires a separate service which monitors a directory for shader
source files, compiles these files into D3D bytecode, and places
the bytecode in the qtd3dcompiler cache directory. This directory is
monitored by qtd3dcompiler, which is then able to then load the blob.
Change-Id: I9889c8d66d2ddbe5a7a1dc44bfe5d8ad229b0e43
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
While QHostInfo and QNetworkInterface are implemented,
socket implementation is just a stub for now. Having
stub implementation is preferable over not having them
at all is because most applications will not build, if
sockets are not available. Even though they do not
do anything useful yet, applications can be compiled
and run to get an idea how network will work on WinRT.
Change-Id: I78ea88901a30280d4098b75ef7398c2628dd19c8
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@digia.com>
Allows post-processing code to exclude recursing into host_build subdirs.
The alternative would be to have the SUBDIRS logic pre-parse the subdir
project to check if it's a host_build, but that might have a performance
impact, so it's better to leave the information explicit in the subdir
project file.
Change-Id: I1a6f7d94c49faf5f5106c83ef21f6b85b531c90b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
As network reimplementation is not in place yet it is disabled for now.
Once I78ea88901a30280d4098b75ef7398c2628dd19c8 is done this can be
reverted.
Change-Id: I042427fff9664fd8b7ea0a59476d6a6bb6b4eaec
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Various global changes, primarily preprocessor flow, to support the
WinRT platform.
Change-Id: I3fa9cf91d5fb24019362e88fcf205e31b4f810b5
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
there is no point in scanning any of it.
qdoc already excludes itself (and will hopefully move out of qtbase
soon), so not adding it here.
Change-Id: I84356c0988be386de331bb7879b3ebd2108526a2
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
bootstrapping is only necessary if we are cross-compiling or have a
circular build dependency.
Change-Id: I17244457652ca9d4fc797043e57070c2ae3ee5d1
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this just factors out the common sources from the qdbus tools, to avoid
double compilation, and to clean up the project files.
Change-Id: I330d108ebffda4bc7c0e0e9ec00e51ddd48d5289
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this is done mainly to resolve spurious dependencies, in preparation
for making some tools not bootstrapped in native builds.
as a nice side effect, there is even more parallelization possible now.
Change-Id: I779cf0059c98c65aba8510bf3d24fdab4eeaa863
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Based on the Necessitas project by Bogdan Vatra.
Contributors to the Qt5 project:
BogDan Vatra <bogdan@kde.org>
Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
hjk <hjk121@nokiamail.com>
Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Paul Olav Tvete <paul.tvete@digia.com>
Robin Burchell <robin+qt@viroteck.net>
Samuel Rødal <samuel.rodal@digia.com>
Yoann Lopes <yoann.lopes@digia.com>
The full history of the Qt5 port can be found in refs/old-heads/android,
SHA-1 249ca9ca2c7d876b91b31df9434dde47f9065d0d
Change-Id: Iff1a7b2dbb707c986f2639e65e39ed8f22430120
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
The complete set of OpenGL extensions is large meaning that any attempt
to incorporate them into a shared library such as QtGui would bloat the
size of that library.
The typical usage pattern for OpenGL extensions is to use only a very
small number of extensions from the total available set. A static
library suits this situation very well as an application will only
compile in the executable code for the extensions actually used. Thus
makign all of the functionality available to those that need it but with
zero cost to those that do not.
Change-Id: I49fdac7e9d2e0b190b7ea04b776018dd63c3065f
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
ANGLE is a component that implements the OpenGL ES 2.0 API on
top of DirectX 9. See the following for more info:
http://code.google.com/p/angleproject/
ANGLE is now the default configuration on Windows. If you
want to use desktop OpenGL, you should build Qt with the
following configure options:
-opengl desktop
To configure Qt to use another OpenGL ES 2 implementation,
you should use:
-opengl es2 -no-angle
Task-number: QTBUG-24207
Change-Id: Iefcbeaa37ed920f431729749ab8333b248fe5134
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
qmake can now produce proper mixed-target projects
Change-Id: I797f055f6e1487b9aefb75eee91d6c2cc4e6e56e
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
they were included instead of being proper subdirs. this doesn't appear
to be necessary for anything at this point.
Change-Id: Ie57285df8e5ea7bd8883bcd42fa6ed62b8e1d54d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this has been a) dysfunct and b) unnecessary for *quite* a while.
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Change-Id: I5d658a15d0c1dc923002f8d773eecb8382cd213d
Instead of the dependency add the one needed function as virtual to
the QPlatformServices in QtGui.
Change-Id: Ia4455f5ac88ec4d0480bd81635cebba62bbd8ac5
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
This needs some build system fixes to let widgets depend on
the platform support library (and be built after it).
Change-Id: I6f5b878971d1002a18e2fd66db4f34ffd0ac939a
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@nokia.com>
testlib now compiles without widget support and it will be great to get
this code path QAed and testable.
Change-Id: Iceb641bf04fdac84ef0a0f86d0abb83f4c66bf80
Reviewed-by: Donald Carr <donald.carr@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
