Remove Windows CE-specific files, #ifdef sections for Q_OS_WINCE and wince
.pro file clauses in library, examples and tests.
Task-number: QTBUG-51673
Change-Id: I102745aaca9d9737f2108fe7618111743d5ae980
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
this fixes static builds by ensuring that all dependencies are exported.
Task-number: QTBUG-51071
Change-Id: Icbce502dcbcb4d4b4d922c42679f44e2cc930bf3
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
This simplifies deployment and makes instantiating accessible interfaces
faster since no plugin needs to be loaded.
[ChangeLog][QtWidgets] Accessibility for widgets is now included in the
widget library instead of being a separate plugin. For static builds
this means that libqtaccessiblewidgets is no longer required.
Task-number: QTBUG-32888
Change-Id: Ie7347898868fd67c1fc568f0d251cbd2ef71e041
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
The resource file that needs to be included is hardcoded whereas qmake
generates one that is based on the target name (which includes the
libinfix). So to ensure the right one is available, a copy of the
generated rc file is done to the name it expects.
[ChangeLog][Platform Specific Changes][Windows Embedded] Fixed building
issue when configuring Qt with -qtlibinfix
Change-Id: I46ddbc5d22424bf63c54423618385e4268790eeb
Reviewed-by: Björn Breitmeyer <bjoern.breitmeyer@kdab.com>
the relevant code moved to the windows platform plugin.
Change-Id: I06f2efd1190ee7d1da1f48172ae879e5c06a945f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
The accessible plugins directory contains a QtQuick plugin
as well as a widgets plugin. We need to specify the correct
one to avoid all widgets applications implicitly depending
on QtQuick on Android.
Change-Id: I72b2ee4fcd2d7914fc2ed7996f504ce2df79842d
Reviewed-by: Christian Stromme <christian.stromme@digia.com>
For bundling Qt, we need two things:
1. We need to build a regular .jar file out of the Java files,
so that they can be built into the app package. Dexing the
classes first (i.e. compiling the JVM bytecode to Dalvik
bytecode) is required for loading the .jar file at run-time,
but cannot be used for building it into the app, so we need
two different paths.
2. We need to specify which extra files have to be bundled for
each module (this is primarily for plugins and imports). This
is because there is no static dependency on these files, so
it cannot be detected during deployment.
Task-number: QTBUG-30751
Change-Id: I733603ee5d1c64bd7c5b9357eb5d993b9d0298f7
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
- Rename dynlist file to reflect the Qt module its used for
- Drop removed functions/methods from dynlist file
Change-Id: I5e2b369f0f62c1daff8086e9dbc3f62150bd26ea
Reviewed-by: Harri Porten <porten@froglogic.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
the "export location" of the linguist tools was just bogus, and lconvert
was missing anyway. the two dbus tools and qdoc were missing, too.
generally, it seems useless to report the paths of some random tools -
instead, just report the install location of the host binaries and let
users figure out the complete paths themselves - this should be ok, as
we decided that distributors are not supposed to do tool renaming any
more.
for the binary path just use the final location, as the files won't be
used before installation anyway. this allows us removing the scary
generic prefix replace from the pc file installs.
and as a side effect this also fixes debug_and_release builds of core
and widgets by not loading various prf files prematurely and thereby
messing up the dir replacement magic.
Task-number: QTBUG-28286
Change-Id: I99de419301fc07fb923959db4bd5cab9072d1c31
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
we were already installing them into QtCore/private, so turn them into
proper private headers to start with. this cleans up our project files.
Change-Id: I0795f79e03b60b5854de9e4dc339e9b5a5e6fd87
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
.qmake.conf (and previously .qmake.cache) already does that for us.
Change-Id: I06cc01fa45921d7bd66dda7a0f88729faeff37bd
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
qdocconf files can now reference $QT_INSTALL_DOCS to pick up e.g. global
includes, instead of using relative paths. Qt modules will automatically
get a doc target that builds and installs into the right place (including
supporting shadow-builds) if they set QMAKE_DOCS before loading(qt_module).
Change-Id: Ia408385199e56e3ead0afa45645a059d1a8b0d48
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
this is more logical, following the qt_plugin and qt_tool scheme.
Change-Id: Ib3b2abec6728cdab260e15128b1cd78e8e6f5d6a
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
this only needs to be set in one module each - the one which provides
the relevant tool.
this is moderately source-incompatible, in that a package which queries
a given variable from the wrong library won't get the path it looks for
any more. as it's likely that everyone was using QtCore as a reference
anyway, this will only affect uic - which is in the new QtWidgets
library, to which people need to adjust anyway.
Change-Id: If05d3c33fda6cd12466e261391b825c59651d3e4
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
absorb module.prf into qt_installs.prf, as that's where it belongs.
add qt_install_module option and automatically set it in
qt_module_config. make qt_installs use that option.
Change-Id: I860616f3a29a456f7b88ddaffa09375400c8911e
Reviewed-by: Joerg Bornemann <joerg.bornemann@nokia.com>
There is no session management currently implemented for the xcb QPA
backend. Update the build system to reflect this.
Change-Id: I3486de5741f1fb7e09330ca142b8235a84d3b91d
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Presumably, this was set for QSound, which has since moved to QtMultimedia (and
no longer uses nas, anyway).
Configure also no longer seems to have logic for setting nas, as of
4535913c4f.
Change-Id: Ie5b351844bd169ad0548b0d29513adbf6f5d9a12
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Donald Carr <donald.carr@nokia.com>
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@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>
Also removed a define which was used only for this purpose.
This change brings the constructors in line with Q{Core,Gui}Application.
Change-Id: I1134ca5611453e8445c1a4f3226846621fa8872c
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
There is no reason these interpolators need to stay in QtWidgets library.
Change-Id: I27db49fea2cfd8f0ef417dc52edf66dd1835e7a1
Reviewed-by: Michael Brasser <michael.brasser@nokia.com>
Reviewed-by: Martin Jones <martin.jones@nokia.com>
After discussion with Liang, I'm reverting it as he requested. This change put every header into the SYNCQT.HEADER_FILES twice for in-source builds, and the qtMODULEversion.h header did not include a path component.
This reverts commit 2fbc45b58bba860abf67fb28aa1319c9f4ededaf
Change-Id: Ie84cef19193ce5e49072f1f67a41140d9d2673b8
Reviewed-by: Liang Qi <liang.qi@nokia.com>
It was put in source tree before.
Task-number: QTBUG-20439
Change-Id: Ib52d9c2e83ae375aad259ddc74138bbc728b3ed0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
To instrument a Qt application or library with the TestCocoon coverage
tool, do `CONFIG+=testcocoon' in the application .pro file.
To instrument Qt itself with testcocoon, use the `-testcocoon' configure
option.
Change-Id: Ie77109a078d11ea51f7a073621e0df9c752c44ae
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
The QtWidgets module doesn't contain any code that needs these custom
compilers (that code has been move to QtGui).
Change-Id: I655e478908bfa0b646e68210f6215d9ffbb1f81e
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
QShortcut stays in QtWidgets, what we need in QtGui
is only the basic functionality of the shortcut map.
QML can integrate directly with the map where required.
Change-Id: Ie39e9242f24cbebf824e5c3d2926880325ea4187
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>