[ChangeLog][Important Behavior Changes] Support for DirectFB is no
longer enabled by default, due to lack of development in upstream. To
re-enable the platform plugin, pass the -directfb option to configure. If
there is no interest in this platform, the support will be deprecated in
Qt 5.7 and will be removed in Qt 5.8.
See: http://lists.qt-project.org/pipermail/development/2016-March/025273.html
Change-Id: Icaa7fb2a490246bda156ffff143c62515a5f575b
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
There was a small logic error in the code selecting the debug/release
C(XX)_FLAGS used when compiling qmake, that could lead to us not
specifying any flags at all.
Change-Id: I5d3c44367d535a17570e3602029b84a02706d624
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
macx-g++ is not supported anymore.
Change-Id: Ibae25768e240d6e8e27c09a345ea02a9b0477fc3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
There's no reason not to allow compiling Qt without any QPA
plugins. It's enough to clearly warn about it at the end
of configure instead of aborting the build.
Change-Id: I52ff681b68fcbfd9c5e28e555224812e6c441dc6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This functionality will get replaced by a new and more flexible system
to configure Qt.
Change-Id: I04cf694ab1671eeed39b79a660566595a22f54a7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
With 5.7, we can rely on c++11 atomics (or the msvc ones), so
the note doesn't make sense anymore.
Change-Id: I10cc67f3dd840f3272ca975c2c9120a8c871a2fb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
so it turns out that the 'unix' conditional in moc.prf meant that the
feature was not enabled *anywhere* by default, as the unix configure
disabled it everywhere.
amends b3fcaea5.
Change-Id: Ie41ed2ebc338e560b8d6bfbb0bb18888e31b6d13
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Make sure we always set the base feature as a flag in qtconfig, and
set the sub-feature in addition if it's being used.
Change-Id: Icfeb0ec1ac9e1a615b5b22eb5fcce47e0e7fc153
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This makes the -separate-debug-info configure optional functional, which
generates dSYM debug info bundles for Qt libraries on Apple platforms.
Task-number: QTBUG-37952
Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: Ia247674740bf450130a15db926df07fa9007e2ca
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Detect if DirectWrite 2 is available, and support color fonts if possible.
One limitation worth mentioning is that if the color font contains regular,
monochrome glyphs as well, then these will be drawn in black, and not in the
pen color. Fixing this would require some elaborate rewrites in the font
rendering system, since we would have to have two font caches per
color font (one for mono and one for colors), or do some sort of trick where
we make argb(r, g, b, 0) mean subpixel alpha instead, and detect glyphs that
are not correctly premultiplied when blitting to the screen.
Another limitation is that the approach does not work with distance field
rendering. In principle we could support this on Windows, since the
format is vector based, but it would also require substantial work and
it is not possible to support for Apple/Google fonts anyway, so it would
just lead to code which is not cross-platform.
[ChangeLog][Windows] Added support for color fonts (color emojis) when
DirectWrite 2 is available.
Change-Id: I6a608dd5d2aa3a7e762a06830902bddac7c550a5
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
These values are artifacts from the past and not used anymore
since Qt 3 times.
Change-Id: Ide2a7b3bd000ec0bc280a5467549c1a974c019e0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The feature is called gtk3, so the naming of the CFLAGS/LIBS should reflect that.
At the same time, remove the unused QMAKE_LIBS_QGOBJECT variable.
Change-Id: I565a098aaa80f380de0da534d058f315e77a33f6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
no-zlib is no longer supported, so these lines can't have any effect.
Change-Id: Ib5ef9a97a0687945606b4a718e339590bc501fe9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The feature is called xinput2, so the defines should have this in their name as well.
Change-Id: I661dd3ea3726f4a0954e788d5f0083ace10bbe89
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Most libs use QMAKE_LIBS/CFLAGS, but some have other naming
conventions. Unify them into using QMAKE_LIBS/CFLAGS.
Change-Id: I39b188adc1f9a223a83b294c5315c3095a9c68de
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
It's 2016, and file sizes larger than 4G are common, so
-no-largefile is something we really shouldn't support
anymore.
For now left the implementation as is, just removed the
configurability from the command line. But this should
really get replaced by decent configure checks that
check for 64bit stat() vs stat64() vs 32bit stat().
Change-Id: I057515e3cc1f06a022d80f02e866944428026b1d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
These are not being used in Qt anymore, we use their
xcb replacements instead where it makes sense.
Task-number: QTBUG-30939
Change-Id: I2d8141818b402c23b29b0c0398f876a6189d0d27
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Compiling the drivers into Qt Sql does not make a lot of sense
anymore, as we handle plugins well enough in the build system
these days.
[ChangeLog][Build system] SQL drivers are now always compiled as plugins.
Change-Id: I364b82a480849399d1fafe4b20e9f08922569260
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Our handling of plugins when Qt is build statically is
nowadays good enough, so we don't need to build the
JPEG and GIF support directly into Qt for static builds.
Let's simply always build them as plugins.
Also simplify the logic in configure, and get rid of the
no-gif, no-jpeg and no-png config variables.
[ChangelLog][Build system] JPEG and GIF image support is now
always built as a plugin. Removed -imageformat-[jpeg|gif]
arguments to configure.
Change-Id: Ic01559ff406c966807b3be8761252e8802adcdf7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This brings the feature name in line with the name
of the define.
Change-Id: Ib56c9c25ce83c396e5085d69efd3fe953c1aadd0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
...instead of overwriting when building qmake for windows.
Change-Id: I89eb33439b03a0ad33d006d12c9896c87d271c4f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The plugin builds as a static plugin.
It is based on the Linuxfb plugin.
It uses the INTEGRITY FB API for framebuffer for display, and HID API
for input (mouse, keyboard, touch).
Because this is the only supported plugin and requires to be included
as a static plugin, automatically add the platform to any application
through qmake.conf.
Change-Id: Ic228afb59cb39dd02c2d538de46caf6e6ea7d153
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
Targets (xplatform) include integrity-armv7 and integrity-x86.
[ChangeLog][Platform Specific Changes] Added support for INTEGRITY RTOS.
Change-Id: If7827791e0a977ff198cb99e9dcc684a010bbb81
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
it is important that the flags coming from the current qt build appear
first, as otherwise a pre-existing qt installation may interfere with
the build.
the windows configure does not have any of this magic to start with.
Task-number: QTBUG-6351
Change-Id: Iacc1d9b5aa9eed9a5f0513baef9f6c6ffcef0735
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
now that we rely on consistently sane runpath semantics everywhere
(--enable-new-dtags on linux; the default elsewhere), there is no use
in forcing our runpath downstream: our libraries will find their
dependencies due to their embedded runpath.
this does not affect qt.prf adding qt's own library path to the user
projects' runpath.
this effectively reverts 42a7eb8df6, and some more.
Change-Id: If7af7be7b7a894bebb9b146ccb0035452223c7ac
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
This test was the old way of checking whether to enable
c++11 functionality. That is now anyway required, so there
is no need for this test anymore.
Change-Id: I083e85a4698cac6bd9b573525c7b977f63e14113
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Simplify the handling in the pro files as well. system-zlib
is the only option deciding whether we use our bundled copy
or the system lib.
Change-Id: Id28c1c64c5944e86f0e9cd3533268f43e98522a1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
We're not currently supporting OpenVG anywhere, so remove
those tests. If we need them in the future, it's easy to get
them back.
Change-Id: I06c0f9f3b3ecaa10a51de84c3059d4eee3a29fad
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Andy Nichols <andy.nichols@theqtcompany.com>
The fonts directory is removed in 5.7. Avoid creating a broken
symlink.
Change-Id: I95d1970737f54810006c084436411fc95743f72d
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This also reverts commit 018e670a26.
The change was introduced in 5.6. After the refactoring, 14960f52,
in 5.7 branch and a merge, it is not needed any more.
Conflicts:
.qmake.conf
src/corelib/io/qstandardpaths_mac.mm
src/corelib/tools/qsharedpointer_impl.h
tests/auto/widgets/itemviews/qlistview/tst_qlistview.cpp
Change-Id: If4fdff0ebf2b9b5df9f9db93ea0022d5ee3da2a4
This section did set some canBuild* variables based on compiler
checks. Apart from canBuildQtConcurrent, the variables never
got used. In the QtConcurrent case, the answer will anyway always
be yes, since we require a c++11 compliant compiler nowadays.
Change-Id: I660b40e96a657f6fa4d32f6b680adf44e70509c9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
