We don't actually detect whether the compiler can create Neon code or
provides Neon intrinsics. Most of them do, so that test would be mostly
moot. We removed the detection previously because we couldn't
automatically enable Neon due to leakage of instructions outside the
areas protected at runtime.
Instead, we rely on the mkspec properly passing the necessary flags that
enable Neon support.
This commit does not change that. All it does is verify whether the arch
detection found "neon" as part of the target CPU features. In other
words, it moves the test that was in simd.prf to configure.
It does fix the Neon detection in configure.exe, which was always
failing for trying to run a test that didn't exist
(config.tests/unix/neon).
Change-Id: Id561dfb2db7d3dca7b8c29afef63181693bdc0aa
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This patch adds the feature use_gold_linker to use the gold linker that
has been part of of GNU binutils since 2008. Gold links C++ libraries
much faster and use less memory.
The feature is autodetected when building Qt on Linux, but can be disabled
in configure. On MingW builds it is default off but can be enabled for
cross builds.
Change-Id: Icdd6ba2e706b2c791bcf44b6e718c2b7a5eb2218
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][configure] The -process/-fully-process/-dont-process options
have been removed due to being unnecessary and counterproductive.
-fully-process has always been broken to a degree under unix (and since
5.0 under windows) - rcc isn't built before running qmake -r, so the
dependencies are unreliable (and there are many warning messages from
qmake).
also, it is a lot slower nowadays, as qmake -r is not parallelized.
-dont-process doesn't make any sense any more - even if you don't need
the Makefile for some obscure reason, the time spent on creating it is
not relevant without the recursion.
this leaves -process as the only option.
Task-number: QTBUG-36955
Change-Id: Ifd3949d9ff773780646c6f65db1629e1c19e53d2
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the generated projects aren't optimal for building qt anyway (as rcc is
not built yet, dependencies are missing), and the added value isn't all
that great to start with (Qt devs typically use Qt Creator nowadays).
the -no-qmake-deps option was also removed, as it affected only -vcproj.
[ChangeLog][configure] The -vcproj option was removed. Use "qmake -r
-tp vc" _after_ building Qt in case you want to use VS to work on Qt.
Change-Id: I0207d1a89a83b70991a63a7d121a9de4cb685ca5
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
If -qreal float is passed, fullCpuArchitecture() will now include
"-qreal_float". If something else other than "float" is passed to
-qreal, we'll try to encode it (e.g., -qreal "fixed<int, 7>").
Change-Id: Ie33fd1a643f4376e6f01a7966e01c7c34e6fcffd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
GCC 4.9 now allows us to #include any and all intrinsics headers, not
just the one for which we're compiling code, a behavior that ICC and
MSVC have had for some time. With that, we're able to have the functions
for different targets in the same source file. See the GCC manual:
http://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html
This functionality is notified by the QT_COMPILER_SUPPORTS_HERE(XXX)
macro, which indicates that all the intrinsics from
QT_COMPILER_SUPPORTS_xxx are available and enabled. To complement, a
QT_COMPILER_SUPPORTS(XXX) macro is also added.
Unlike ICC and MSVC, GCC requires a special function attribute, which
will also cause code optimization. That's the QT_FUNCTION_TARGET macro.
Note: because of the absence of the target attribute, ICC and MSVC will
not generate instructions with the VEX prefix unless they only exist
with the VEX prefix or if -mavx / -arch:AVX are enabled.
Change-Id: I0c1880c20324bd8e0fc68a863e36d1fa7755dff0
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@digia.com>
This injected quite some code on every use of qDebug and friends,
while not giving any measurable performance benefits.
Change-Id: I7b51f99130f18f1252da01e313f7b97c43a5480d
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This matches the -ffunction-sections from bootstrap.pro, which tells the
compiler to create a section for each function. The -gc-sections option
tells the linker to drop what wasn't used (normally, it only drops
entire files).
Before (on Linux, built with -O3, no LTO):
text data bss dec hex filename
1746385 7920 3750 1758055 1ad367 bin/moc
1444101 6664 1894 1452659 162a73 bin/rcc
4407725 1568 4896 4414189 435aed bin/qmake
After:
text data bss dec hex filename
1131655 6520 3494 1141669 116ba5 bin/moc
1027043 5480 1766 1034289 fc831 bin/rcc
3578489 1656 5313 3585458 36b5b2 bin/qmake
Gain: 35% on moc, 28% on rcc, 19% on qmake
Before (on OS X):
__TEXT __DATA __OBJC others dec hex
1495040 12288 0 4294993008 4296500336 100176470 bin/moc
1265664 8192 0 4294983904 4296257760 10013b0e0 bin/rcc
5279744 81920 0 4297912320 4303273984 1007ec000 bin/qmake
After:
__TEXT __DATA __OBJC others dec hex
806912 8192 0 4294988132 4295803236 1000cc164 bin/moc
720896 8192 0 4294979764 4295708852 1000b50b4 bin/rcc
4841472 77824 0 4295580688 4300499984 100546c10 bin/qmake
Gain: 46% on moc, 43% on rcc, 8% on qmake.
Change-Id: Icc7cdc9fd6f5db15537b4adabaac7e7a27e539d4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This might lead to a smaller binary if we use --gc-sections too.
Change-Id: I7e17b956a85ecefc3e187054848393d2855152b6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Do not link against ICU on Windows, unless it is explicitly requested
('-icu' configure option). This removes the QtCore->ICU dependency
if ICU was detected in the configure environment.
So far ICU has been used in Qt Core for
- support of a larger set of codecs (805 instead of 135)
- more accurate QLocale functionality (QLocale::toUpper,
qLocale::toLower)
- string collation
However, for all functionality there are also backends using the
Windows API/Registry (QLocale, QCollator), or built-in
codecs that are part of QtCore. Since the ICU dependency is quite heavy
(3 libs with about 25 MB) it seems sensible to not require it by default.
QtWebkit is unaffected, since it has it's own ICU check.
[ChangeLog][Windows] Changed configure defaults so that Qt5Core does not
link against ICU libraries anymore. Pass '-icu' to enable it.
Task-number: QTBUG-38259
Change-Id: I3fd3e8ac0f091f532b04945718c0e4a3cc71a087
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
It has been fully obsoleted by 4255ba40ab.
This reverts commit 99eecab83d.
Change-Id: Id7b8d3bba27ff43e38e4fe32a4f2950de9ced493
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: John Layt <jlayt@kde.org>
There is no valid reason why separate debug info support is missing
from the win32 configure app. It can be used with proper cross
compilation tool chains.
Change-Id: I5cf5fba24abc3b515f893a3f5b799a0644fd3218
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
151cf2047a broke cross-compilation
for Android on Windows, since evdev-support was detected, but
there was no corresponding test to disable the mtdev-code in the
evdev files.
Task-number: QTBUG-38155
Change-Id: Ifb08fa1160a348ef64b970a89922e66dc6ddd263
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This isn't needed anymore since quite a while.
Change-Id: I80a99f988a917af5b8c64865ec7e73e519978740
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
To enable windows xp support, we must do two things:
1. linker flag must be /SUBSYSTEM:CONSOLE,5.01 or
/SUBSYSTEM:WINDOWS,5.01. For x64, the version is 5.02.
2. Do not use Windows Kit 8. Win SDK v7.1A is recommended. Prepend the
right include paths and lib paths to INCLUDE and LIB before
building.
The Windows XP target support is enabled by passing "-target xp" to
configure.
Task-number: QTBUG-29939
Change-Id: I84c8439606cc2a9d27d64947702846faa4f1e4a2
Reviewed-by: Lucas Wang <wbsecg1@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Evdev is not known to the windows configure and therefore some code
is currently broken which depends on QT_NO_EVDEV. This patch
introduces evdev to the configure app on windows and disables
evdev support for cross compilation if not available.
Change-Id: I6acb5b593668c85a19ef8658a8d4c36ec3d2a686
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Pass the -confirm-license option to external license checker which is
used in Qt commercial version.
Change-Id: I62326d1e6a8307dae64535ecf2ced762130b7e8f
Reviewed-by: Miikka Heikkinen <miikka.heikkinen@digia.com>
Reviewed-by: Samuli Piippo <samuli.piippo@digia.com>
Enterprise only license key handling removed from configure.
This does not affect the functionality of the Open Source version nor
the enterprise version.
Change-Id: I01736eba3066c56b6e50e022fae8de6aa9bd884b
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Remove definition QT_EDITION which was set in configure
since it is not used anywhere anymore.
Change-Id: I5c30ab47c6244fcb07707fd05e11decf2068f6d1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Qt 4 used to have it called LICENSE.GPL3 since we used to have GPLv2 as
an option before Qt 4.5 (which is when we added the LGPL v2.1). Looks
like no one realized that the configure script looks for that file when
LICENSE.GPL was added to the modularized repositories...
Task-number: QTBUG-37175
Change-Id: Iffb35adf128c3e49a7a0c12dbccd5ebe9bccf3f2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
less platform-specific code. the qfeatures.h generation is already here.
Change-Id: Ied69fb431eed5816fbff63b33be431ee913c2bc8
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
Added configure test, whether lgmon (liquid graphics performance monitor)
is available. The test is supposed to be positive only for internal
BlackBerry NDKs currently.
Added calls to initialize lgmon and to indicate when an app is ready for
user input.
Change-Id: I5cbc29fb38a86585dcebd14d462436deaa1998aa
Reviewed-by: Wolfgang Bremer <wbremer@blackberry.com>
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Use the same logic as in the Unix configure script, and disable
"widgets" if "gui" is disabled.
Change-Id: Ica338ad10b965eea297dddaaedeea61a3ae3ebe9
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Add the required printsupport plugins to the QTPLUGIN variable
as is done for the QPA plugin.
[ChangeLog][QtPrintSupport] Made the Qt buildsystem automatically include the
necessary plugins so that static applications can print.
Task-number: QTBUG-29663
Change-Id: I0e2e3b0f25dd5714bd187711c85893926b0c4e85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When MSVC supports ref-qualified members, we need to ensure that
qstring_compat.cpp can see the non-qualified definitions in qstring.h,
which means no precompiled header.
Alternatively, for a bootstrapped build we could not compile
qstring_compat.cpp or #ifndef the functions.
Change-Id: I8ece34503060f0b4b0f8f2df2fb9b0fb1311e269
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Previously the linker options were overquoted which resulted in
a broken Makefile.
Change-Id: I2a77ad07564fc75533d6e8f29b5cbe52389bcce5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Commit 773dd01 introduced a general mingw platform scope, which
is cleaner and more flexible than matching the spec name.
Change-Id: Ie3a9cb791a83f7c8a51bc4e23069190c452ab521
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Fixes ARM build, as the NEON drawhelpers and image conversion functions
were ifdef'ed out.
Follow-up to 1b12c0608b.
Change-Id: I0b5e89c8f445741432db2dfe1f8d971b971c8605
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
the diff -w for this commit is empty.
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I77bb84e71c63ce75e0709e5b94bee18e3ce6ab9e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is an alternative plugin for the windows platform. It shares most
code with the current windows plugin, but substitutes a direct2d-based
paint engine for window backing stores and pixmaps.
Change-Id: I78fafd9c5871fa090b49436f5b40ec80f8789f8b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Those libraries are contained in QMAKE_LIBS_CORE and
GetSpecialFolderPath() is present in all supported versions.
Change-Id: Iae40714e0f234625b063aeb50e29fc79c4aaa6ea
Reviewed-by: Björn Breitmeyer <bjoern.breitmeyer@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
While there is no implementation for accessibility yet, enabling it allows
the interfaces to be used and an accessibility plugin to be developed
for this platform.
IAccessible2 and MSAA bridge autotests are disabled for this platform.
Change-Id: I2bfd07f6b21ca469b27d88ef11df723ac8ff8202
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
This is the first step in implementing an in-place conversion of QString
to QByteArray. This requires ref-qualifiers in member functions so we
know that we have an rvalue QString.
Converting from UTF-16 to Latin1 always requires half the memory.
For conversion from UTF-16 to UTF-8, the typical string will also need
the same memory or less: characters from U+0000 to U+007F consume one
fewer byte; characters from U+0080 to U+07FF and from U+10000 to
U+1FFFFF occupy the same space in UTF-8 and UTF-16; it's only the ones
from U+0800 to U+FFFF that consume more space in the UTF-8 string.
For the locale's 8-bit codec, we can't be sure and the code (currently)
needs to go through QTextCodec anyway.
This requires a #define set before #include'ing "qstring.h". However,
since qstring.h is included by the QtCore PCH, we need an extra qmake
compiler without the PCH flags to compile this .cpp.
After this change, the distribution of calls in QtCore, Network, Gui,
and Widgets is as follows:
const & &&
toUtf8 31 (74%) 11 (26%)
toLatin1 79 (77%) 24 (23%)
toLocal8Bit 26 (16%) 138 (84%)
Change-Id: Idd96f9ddb51b989bc59f6da50054dd10c953dd4f
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Otherwise build will be broken due to no support for it.
Change-Id: If5ccd7fbcf8340600c5b12081ac4f7e2c6b420fd
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
For the conflicts in msvc_nmake.cpp the ifdefs are extended since we
need to support windows phone in the target branch while it is not there
in the current stable branch (as of Qt 5.2).
Conflicts:
configure
qmake/generators/win32/msvc_nmake.cpp
src/3rdparty/angle/src/libEGL/Surface.cpp
src/angle/src/common/common.pri
src/corelib/global/qglobal.h
src/corelib/io/qstandardpaths.cpp
src/plugins/platforms/qnx/qqnxintegration.cpp
src/plugins/platforms/qnx/qqnxscreeneventhandler.h
src/plugins/platforms/xcb/qglxintegration.h
src/widgets/kernel/win.pri
tests/auto/corelib/thread/qreadwritelock/tst_qreadwritelock.cpp
tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp
tests/auto/gui/text/qtextdocument/tst_qtextdocument.cpp
tools/configure/configureapp.cpp
Change-Id: I00b579eefebaf61d26ab9b00046d2b5bd5958812
For plugins that are built with a different (but binary compatible)
MSVC runtime than Qt is built with, the plugin's embedded manifests
prevent a successful loading of the plugin.
There's no need for having the plugins tied to a certain CRT version
as they are bound to Qt's CRT version.
Task-number: QTBUG-1297
Change-Id: I6ae4cadd99ee4657e613b07a40141a7bae08424f
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Plain QNX 6.5.0 does not have a libpps, the new QNX
has a libpps and BlackBerry has it as well. So we need
a configure check to not open another mkspec for this
platform. This fixes the plain QNX 6.5.0 build.
Change-Id: Id4b3876f2385bcb5f3df426945532e7e26133f24
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
