Now that -l and -fw options are gone, using a combined EXTRA_LIBS
makes no sense anymore and only complicates things.
Change-Id: Ic12bf482f3bed041aff7f0891f008b1f34ae2b4d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
These arguments were nonsensical, as they would lead to every single Qt
module linking to those libraries. This was probably some left-over from
old times, when Qt was just a single library.
Change-Id: I0343a6df270fd0d2efa5333ba4e457670f5d0910
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
angle is an implementation of es2 and thus autodetected if es2 is
requested.
but this also means that it is actually *not* mutually exclusive
with dynamicgl - quite the opposite. express that sensibly in the
build system. this implies that we will now get sensible messages
from configure if angle is not detected while building with dynamicgl.
furthermore, this simplifies the handling of defaults, removes the
unnecessary case in checkAvailability() (checkAngleAvailability() is
always called directly), fixes the complaint on winrt if gles2 is
disabled, and avoids redundant checks for the purpose of obtaining
an error message.
Change-Id: I3373f0ad7d5484d1bac8dbde3f8ee6fca89ebcb8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
-embedded is dead since 187ea846a6, and -arch is obsolete since ba6952b28
(both 2012).
Change-Id: Ife107c4f2ea26f62ce675544b7ad5c06630f5631
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This was only used to specify XP as a target which is
not supported on 5.8 anymore. Clean up all associated
special handling in the mkspecs and pro files.
This effectively reverts change 10a0ac75.
Change-Id: I420d73002912989f1a5be961a2d09277ec4a4425
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
There is a config test for DirectWrite we should run, so
use that instead of autoDetect=false in the new system.
Also, don't add the feature to the CONFIG variable in
configure.exe, as it's not used that way anyway.
Change-Id: I9266ccda8405adce765eac8f0435d723c6bc6f1f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The flag is not used anywhere anymore, so let's simply get rid
of it.
Change-Id: I0c395d18e7f0ef5af03c352753ebb537f5ae27dc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
And ask the user to apply one of the patches we're carrying to their
Standard Libraries.
Change-Id: I7e6338336dd6468ead24ffff141139c79056922e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This option hasn't done anything for quite some time, let's
get rid of it.
Change-Id: Ic6f2830aaf69ba2d054ce21f0d144a61ddf5d06b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Since the system proxies are on by default now then we turn off
libproxy support by default so that there is no risk of a conflict
occurring.
For instance on Linux, it is possible that libproxy indirectly causes
KDE 4 libraries to be loaded which will cause a conflict with the Qt 5
libraries. Therefore we turn it off by default, since the system
proxy setting is the overall better one to have.
[ChangeLog][Important Behavior Changes][QtNetwork] libproxy is now
turned off by default. Configure with -libproxy in order to enable it
again.
Task-number: QTBUG-53649
Change-Id: I0c6c5b9091dc2b2b7662fd44f2a1b49c622e563f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
Reviewed-by: Richard J. Moore <rich@kde.org>
By changing the system proxies option default to being on, we
set it to be the more natural default setting. This is down
to the fact that people tend to assume that this is already
the default option.
[ChangeLog][Important Behavior Changes][QtNetwork] Proxies from
system settings will now be used by default. Configure with
-no-system-proxies to disable.
Change-Id: Iec5bbde9dff1311ce44418f6aa024bda05388cf6
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Richard J. Moore <rich@kde.org>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Peter Hartmann <peter-qt@hartmann.tk>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
This fixes a long-standing issue for Qt packages, where the
paths detected at configure time do not necessarily match the
paths on the user's machine. Hence they have been stripped
manually from qconfig.pri so far, preventing moc from resolving
some includes.
The same logic in configure is left alone for the time being,
since the paths there are also used to filter paths returned
by pg_config and mysql_config. I expect that this will
eventually be removed too in a bigger refactoring going on
right now in dev.
Asking the compiler for implicit paths only works for non-msvc
builds - that is, gcc, clang and icc fortunately have a
compatible way to retrieve the paths. MSVC works
solely on environment variables, which will be taken into
account by a separate patch.
[ChangeLog][qmake] The implicit compiler directories that
moc needs for resolving include files are now determined
when qmake runs. So far QMAKE_DEFAULT_INCDIR was determined
at configure time, which might be wrong for relocated
installations.
Task-number: QTBUG-52687
Change-Id: If0706e8c56a5aca2b6e777e79e90342c498726f3
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This info wasn't really very helpful, and would anyway always
contain either Preview, OpenSource or an empty string for
commercial users.
Change-Id: I311b991834fa83cf1a183083acd5112cda3d2e41
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
clearly, "the windows configure does not have any of this magic to start
with" was flat-out wrong.
Task-number: QTBUG-53312
Change-Id: I80ac10bc8b1581e61c57fcd97f25626990d120ec
Reviewed-by: Konstantin Tokarev <annulen@yandex.ru>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
FontConfig requires FreeType, so choosing the system FontConfig (there
isn't a bundled FontConfig) means that the system FreeType must be used.
QNX ended up configured to include the bundled FreeType and the system
FontConfig which produced a fault when bundled FreeType structures got
passed through FontConfig to the system FreeType.
Task-number: QTBUG-52578
Task-number: QTBUG-51417
Change-Id: I56add73d34320c1d08f63b57cb0fef1ba06264e8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
While we on Linux will do a compile test to check for a
system zlib, the test on a Windows host was less accurate, causing
us to compile in the zlib from 3rdparty/ here. This caused compilation
errors after updating the freetype font engine to support color fonts,
since the zlib in 3rdparty/ was included implicitly in the freetype
library, and since it depends on Qt headers, the compilation failed
in this context.
The hotfix is to force system zlib on QNX for Windows hosts, since
we know it is available in the NDK. Doing a proper build check is not
worth it right now, due to future plans for changing configure. We
will still break for an explicit -qt-zlib compilation, so the plan is
to fix this in an upcoming commit by separating libpng into
a library.
The hotfix just follows e6cb3b8c.
Task-number: QTBUG-53248
Change-Id: I07dd4356fae6397b3cc93fc1fa97bf35380e19df
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
While we on Linux will do a compile test to check for a
system zlib, the test on a Windows host was less accurate, causing
us to compile in the zlib from 3rdparty/ here. This caused compilation
errors after updating the freetype font engine to support color fonts,
since the zlib in 3rdparty/ was included implicitly in the freetype
library, and since it depends on Qt headers, the compilation failed
in this context.
The hotfix is to force system zlib on Android for Windows hosts, since
we know it is available in the NDK. Doing a proper build check is not
worth it right now, due to future plans for changing configure. We
will still break for an explicit -qt-zlib compilation, so the plan is
to fix this in an upcoming commit by separating libpng into
a library.
Change-Id: I7854c3c762fa37f7ee4b5f1112dbae8b5973ea86
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Make REDUCE_EXPORTS the default for QNX. This is what the Linux builds
use. The Windows builds should too.
Turn on ICU detection for QNX. QNX has ICU.
Task-number: QTBUG-52578
Change-Id: Ie65c6ff03c4eecf361727b3b6026338f686d9749
Reviewed-by: Dan Cape <dcape@qnx.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
While this wouldn't have any consequences in practice, it was
perceived as confusing to users that Directwrite 2 was listed
as enabled in the summary when Qt was configured with -no-directwrite.
To give a better presentation of what will actually be compiled,
we force disable Directwrite 2 when Directwrite is disabled.
Task-number: QTBUG-52952
Change-Id: I779772ecc4d47b20854588cedde2b097ae22ded4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Use size_t as index type for C array.
Change-Id: I0980f47ef881108c9639a2a73fbb878b7d8161d2
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>
Give the Windows configureapp the same -pch/-no-pch arguments found in
the Linux configure script. Using command line arguments to
enable/disable precompiled header use is preferable to mkspec changes.
Make -pch the default for all toolchains. In particular, this makes
-pch the default for QNX on Windows. Previously, QNX on Windows had
an implied default of -no-pch. Precompiled headers are the default
for QNX on Linux; they should also be the default for QNX on Windows.
A 'dictionary["PCH"] = "no"' will need to be added in
Configure::applySpecSpecifics for any toolchain that should default to
-no-pch (none known at this time).
-no-pch is implemented by putting a "CONFIG -= precompile_header"
in qmodule.pri. This ensures that Qt is built without precompiled
headers (as requested) even if allowing precompiled header use is the
default for the toolchain.
Task-number: QTBUG-52578
Task-number: QTBUG-11545
Change-Id: I1b59bc2d416c5ba169161c5b3cc13accd76eeac8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
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>
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>
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 fix repairs the mechanism to deploy Qt dlls as well as C++ runtime
to a wince target in Visual Studio.
Do this by adding a deploy section in the Visual Studio solution and
adding the C++ runtime from the mkspec to the files deployed to the target.
Deploy target path is set to what the wizard of Visual Studio defaults to.
Before, the c++ runtime was only deployed for executables which were built
as part of Qt.
Task-number: QTBUG-50924
Change-Id: I478010dc16e35c68578281895aa3ae14b5c96bb4
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
Remove outdated configure defaults to support features that get
autodetected.
Change-Id: Ia802ccd3fe9defa97e2667e81dff6e815a7b45b3
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>