It only applied to Windows (not MSVC, like the help said) and the build
was broken with this option. So remove it, as we clearly never test
this.
[ChangeLog][Windows] The -no-rtti configure option was removed, as Qt
5.8 fails to build under that condition. To disable RTTI on user code,
add to your .pro file: CONFIG += rtti_off.
Change-Id: I2bc52f3c7a574209b213fffd149aae1b8d0cf9df
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Commit 9ca635482d renamed the configure
feature from pcre to pcre2, which unfortunately means that people would
have to change their build scripts to pass -qt-pcre2 instead of
-qt-pcre. As the configure check already verifies the correct PCRE
version for use (when using the system library), it seems more
convenient for our users to retain compatibility and call the configure
feature "pcre" again.
Change-Id: If26e7888814d8204d43baf7298d9916a4f856a48
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
QtWebEngine requires this in order to disable code that is not allowed
on the Mac App Store. The option is too generic to go directly into
QtWebEngine however, as it can be used to toggle additional features in
qtbase as well as on platforms other than macOS.
Change-Id: I556298f4b654a8904c33002ef097a75e2e38938e
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
in its current form, it was introduced only in 5.7, mostly as a side
effect of -external-hostbindir (which is now handled differently).
it only ever worked for the macOS and MinGW specs, as a side effect of
them supporting -sdk and -device-option (for good reasons), and was
supported only by the unix configure. it's not believed to be really
useful and complicates matters somewhat, so get rid of it again.
should it ever become actually relevant, it can be re-introduced
properly, probably along with a -host-sdk option for macOS.
Change-Id: Ib078469ea39deb821c7b6a8c67fda9e1a95fedf5
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
PCRE1 is going towards EOL. PCRE2 is the way forward in terms
of new features, performance, and security improvements. The
APIs that QRegularExpression uses are similar so the required
modifications aren't extensive.
The biggest difference comes to JIT-compiling of the pattern.
In PCRE1, JIT-compiling did not modify the processed PCRE pattern,
but returned a new chunk of data.
This allowed multiple threads to keep matching using the same
processed data and NULL for the JIT data, until a thread
JIT-compiled and atomically set the shared JIT data to the results
of the compilation.
In PCRE2, JIT-compiling _modifies_ the processed PCRE pattern in a
way that it's thread unsafe [1]; the results of JIT-compilation
are stored somewhere inside the processed pattern.
This means the above approach cannot work -- a thread may be
matching while another one JIT-compiles, causing a data race.
While waiting for better workarounds from upstream, employ a
read/write mutex to protect the matching from JIT-compilation.
[1] https://lists.exim.org/lurker/message/20160104.105831.3cb25b39.en.html
[ChangeLog][General] QRegularExpression now requires the PCRE2
library, at least version 10.20. Support for the PCRE1 library
has been dropped. A copy of PCRE2 is shipped with Qt and will
automatically be used on those platforms which lack it.
Change-Id: I9fe11104230a096796df2d0bdcea861acf769f57
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This also allows us to enable auto-detection for it.
Change-Id: I7639ab533553f02e691e6f6b8cdd8dff19d91809
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
- generic --* options are defined to be booleans, without the
possibility of having an additional parameter
- -qt and -system options don't exist in the --* form
- --foo=bar options exist only in the --* form
Task-number: QTBUG-55610
Change-Id: Ib0480ac6f479df48045c9de8e854a525862ee363
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
... including a [-no]-ico command line option.
Change-Id: I3cb13d2be72b512f72f8dcdb9de72e7a99e36e47
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Adapt configure.exe to use qmake to do most of the work of configuring
Qt. This unifies a large part of our configuration system between Unix
and Windows. configure.exe is now still doing the license check,
creating qconfig.cpp, building qmake, and not much more.
On the way, re-implement the still missing Windows-specific tests with
the new system.
The opengles2 vs. opengl-desktop conditions got a bit convoluted, as
Unix prefers desktop GL, while Windows GLES2 (via ANGLE). Superficially,
there is a circular dependency, but the platform scopes are supposed to
break it.
Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: Ia1941f2c34b7f5bd4990a7673cd737361381c2e7
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
specifically, make configure.bat dump the text file (which got some
windows-specific adjustments).
incidentally, this change removes the need for including a pre-built
configure.exe into our source packages.
Change-Id: Ib3515c113f3602767554fe1493df226551a7bf10
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
that is, save it to config.opt and recall it when -redo is used (and do
not write it again in this case).
a trivial config.status is still created, as having it is very
convenient when shadow-building.
Task-number: QTBUG-38792
Change-Id: I5e9f7374d6bfc60c427cbfd5e9b3e68bfcaae9f2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
it is sometimes desirable to override values from the mkspec without
modifying (or wrapping) the spec itself. linux distributors do this on a
regular basis.
so far, we'd pick up CFLAGS, etc. from the environment, in a somewhat
autoconf-like fashion. however, over time, this approach proved
problematic: the concept doesn't mix particularly well with mkspecs to
start with, is unexpected (and therefore causes frustration), and
doesn't mix well with cross-building (at least the way it was realized).
ironically, it was implemented this way (quite a while ago) upon my
explicit request ...
the new mechanism uses explicit variable manipulations on the configure
command line, just like qmake itself understands. as it happens, this is
again quite similar to autoconf-generated configure scripts. however,
this time around we don't pretend to be actually autoconf-like, so we
also don't try to map any variable names (some of which have different
semantics anyway).
this commit also eliminates the last use of the QMakeVar() function,
so delete it and the underlying infrastructure.
Task-number: QTBUG-32530
Task-number: QTBUG-42962
Change-Id: Id31a6b80e1add08ca21f5b178614bda530d12374
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Add the command line options supported by the windows version of
configure and respect them when running our configure tests.
Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: I1206d60a177e251540d34d232c73c930847564b3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
it's really a bit weird that the windows configure has more options to
configure unix features than the unix one, even if some are just
workarounds for missing auto-detection.
unlike in configure.exe itself, -posix-iconv is now also understood for
symmetry with -gnu-iconv and -sun-iconv.
Change-Id: Ic15376e5822e43b998bd17f02c11e5dd0567dc2b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
- remove the redundantly listed -no-* options and indicate the defaults
differently
- completely regroup the options into somewhat logical sections
Change-Id: Iaa87c2f3749944cd3fc2ec18975767c04892f746
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
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>
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>
