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>
There should be a clear QWidget free path for people with no interest in
legacy QWidget functionality. Adding this option to configure makes this
path readily accessible and hence testable.
Change-Id: If87c1063fcf4c46f5280836126c11999feaa9f8a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Removing (some) stale assumptions about dependencies from src.pro file
Change-Id: I713e3ad8c164321ef035e6c62b25e18e45d1d3ef
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
a project can rightfully expect a sane environment. $$fromfile() does
not necessarily provide that. so instead use include() with a target
namespace.
Change-Id: I8d6d30ab1b760d4930c9b4453bc92f8f8ad0b0ae
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Windows CE has no printing support, so we
can disable this.
Change-Id: I0ec83dff2d045de56d613cd676e9eb290145bf41
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Replace the QDom based code in qdbusxmlparser
with code using QXmlStreamReader.
Task-number: QTBUG-20856
Change-Id: I294e3ebd6faa813c20806be3ae225ac00befb622
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QtV8 library is going to live in the qtjsbackend module.
Change-Id: I72251316163829411dda998b9503ce6f75b3606a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Aaron Kennedy <aaron.kennedy@nokia.com>
Reviewed-by: Kent Hansen <kent.hansen@nokia.com>
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
During shadow-building it was noticed that executing make install
did not actually build mkv8snapshot and therefore caused an error.
Change-Id: I126cdbaffb85170e25412b93bc99af79ac6f4642
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Clean up and remove Symbian specific code and
data.
Change-Id: I89976fd087d485e04d37eccd3aeb3d2beac59b0a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Without this make -jx would often fail as some of the
dependencies of the platformsupport lib weren't built
yet.
Change-Id: I1e4fea5fa6f0dd5751b6b53458f1f14bfeb225b2
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Qt/Embedded and Symbian are no longer supported.
Change-Id: Ifb86a384c666f389a166efe798d4792115731adb
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
When v8 is enabled, QT_CONFIG contains "v8".
There is no "no-v8", meaning that v8 was built
regardless.
Change-Id: I66740b23e5f7cae80740576ea0f13c3ad2f9ad40
Reviewed-on: http://codereview.qt.nokia.com/4073
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
