This reduces unnecessary OS conditions in qmake since these platforms
are mutually exclusive, and also opens up their potential for use on
future devices (like carOS(?), which is device idiom '5').
This is also more similar to what Xcode does, as the
TARGETED_DEVICE_FAMILY variable is not platform specific.
Change-Id: I29d209cd8e0779f492bda829008264773e13c75c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This reduces unnecessary OS conditions in qmake since these platforms
are mutually exclusive, and also opens up their potential for use on
macOS to transparently support multi-arch builds like UIKit platforms.
This is also more similar to what Xcode does, as the DEPLOYMENT_TARGET
variables are platform specific, while the ARCHS variable is not.
DEPLOYMENT_TARGET has a use case for being OS specific in qmake (host
tools vs targets), while ARCHS does not.
Change-Id: Icee838a39e84259c2089faff08cc11d5f849758d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This patch moves towards a more sensible layout for UIKit platforms,
where both the device and simulator architectures for binaries are
combined into a single Mach-O file instead of separating out the
simulator architecutures into separate _simulator.a files.
This approach is both more common in the iOS ecosystem at large and
significantly simplifies the implementation details for Qt, especially
with the upcoming support for shared libraries on UIKit platforms.
This patch takes advantage of the -Xarch compiler option to pass the
appropriate -isysroot, -syslibroot, and -m*-version-min compiler and
linker flags to the clang frontend, operating in exactly the same way
as a normal multi-arch build for device or simulator did previously.
Exclusive builds are still enabled for the xcodebuild wrapper Makefile,
which builds all four configurations of a UIKit Xcode project as before,
as expected.
A particularly advantageous benefit of this change is that it flows very
well with existing Xcode workflows, namely that:
- Slicing out unused architectures is handled completely automatically
for static builds, as an executable linking to a library with more
architectures than it itself is linked as, the unused architectures
will be ignored silently, resulting in the same behavior for users
(and the App Store won't let you submit Intel architectures either).
- Removing architectures from a fat binary using lipo does NOT
invalidate the code signature of that file or its container if it is a
bundle. This allows shared library and framework builds of Qt to work
mostly automatically as well, since an Xcode shell script build phase
can remove unused architectures from the embedded frameworks when that
is implemented, and if Qt ever starts signing its SDK releases, it
won't interfere with that either (though binaries are just resigned).
Change-Id: I6c3578c78f75845a2fcc85f3a5b728ec997dbe90
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This is done because a followup patch will cause simulator_and_device builds
to no longer use exclusive builds and so this feature could not work,
but it is not strictly necessary anyways because users do not need to be
able to do this.
Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: If869fbfea776751553c352c2d652edf745a3638d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The actual blocker for precompiled headers is not the iOS/tvOS/watchOS
platforms, but the way qmake handled multiple-architecture builds on
Apple platforms.
This patch allows multi-arch builds to be performed while using
precompiled headers.
Since df91ef3d6c55692a0236f67b6c6b134a3bf84098 (April 2009), Clang has
had support for PCH files in the driver, which allows to use the
-include flag to automatically translate to -include-pch. We can then
take advantage of the fact that the -include option is allowed to not
be separate from its argument, which lets us take advantage of -Xarch to
specify a per-architecture precompiled header file.
This is done through some magic in the qmake Makefile generator which
"multiplexes" the PCH creation rule across multiple architectures and
replaces a series of tokens with the proper precompiled header paths
and architecture flags at usage point.
Change-Id: I76c8dc9cda7e218869c2919f023d9b04f311c6fd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
iOS was excluded in 09aeda21b9, probably
unnecessarily. The build has been found to be warning-free.
Change-Id: I81de2fff40938b6ab9f7a6a5b9f08f8a8baadb16
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
No need to get libs flags other than -L and -l, since we're adding
everything to the LIBS variable in qmake anyway. We wouldn't want rpath
or other linker flags to leak through.
Change-Id: I7d42fe4b581e49df891cfffd146fab61fecbc5c9
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
that variable is not modified in this scope, so there is no point in
exporting it here. it was probably a leftover from an earlier version.
amends c0cc50520.
Change-Id: Ic6f93d8c38d547308aa88ef337fe49bda004b337
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
they are build-time generated, so they must go to the build dir
irrespective of whether we're using pre-synced headers.
Task-number: QTBUG-55585
Change-Id: I5f10b35c40b0ae2ddc5568d70e254b787ac3f914
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
we need to suppress another qtConfig(simulator_and_device) check during
the configuration phase.
amends 60985aa4.
Change-Id: Iae279d282d47b4c254b7a6f9f33315abe126eff0
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
cf53aa21bf and 3aaa5d6b32
were reverted because of reconstruction in 5.7.
defineTest(qtConfTest_checkCompiler) in configure.pri is smart
enough to cover the case in a9474d1260.
DirectWrite: Fix advances being scaled to 0
Since 131eee5cd, the stretch of a font can be 0, meaning
"whatever the font provides". In combination with ec7fee96,
this would cause advances in the DirectWrite engine to be scaled to
0, causing the QRawFont test to fail.
Conflicts:
configure
mkspecs/features/uikit/device_destinations.sh
mkspecs/features/uikit/xcodebuild.mk
src/corelib/global/qglobal.cpp
src/corelib/global/qnamespace.qdoc
src/plugins/platforms/cocoa/qcocoamenuitem.h
src/plugins/platforms/windows/qwindowsservices.cpp
src/plugins/platformthemes/gtk3/qgtk3dialoghelpers.cpp
src/plugins/platforms/windows/qwindowsfontenginedirectwrite.cpp
src/widgets/kernel/qapplication.cpp
tests/auto/widgets/dialogs/qfiledialog/tst_qfiledialog.cpp
tests/auto/widgets/dialogs/qfiledialog2/tst_qfiledialog2.cpp
Change-Id: I4656d8133da7ee9fcc84ad3f1c7950f924432d1e
Previously we hardcoded the minimum windows version to the initial
Windows 10 release. However features have been added which require a
higher SDK version (eg drag and drop). Deploying such a package might
fail during distribution to consumer devices.
Hence introduce WINRT_MANIFEST.minVersion and
WINRT_MANIFEST.maxVersionTested as variables for the manifest file. If
nothing is specified, both values will be set to the UCRTVersion
environment variable, implying the development setup from which qmake
has been invoked.
Change-Id: I1dcf1e75c67c4ab2fd5a3fdcc32c8783a336e6ff
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
there is no point in doing that, as we don't load it in that case
anyway. in fact, it would lead to caching a new result in every run.
Change-Id: Ia5cb27fa8a5d705d7f32a785b1e3b944f92d8929
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
as these tests do nothing but validating the command line, caching the
result is more confusing than anything else.
also make the tests silent, so they don't clutter an otherwise fully
cached configure run.
Change-Id: Ifc3d65278769b36a056650f077fd6274a7e192e7
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
instead of saving the files away and restoring them afterwards, use the
new and shiny discard_from() function to throw away everything the files
might contain.
strictly speaking, this is not precise, as the pris may also use *=, -=,
and possibly other operations which cannot be trivially undone, but the
purpose is essentially to discard the special outputs of some features
which may affect subsequent tests, for which this is sufficient.
as a side effect, the failure to load qmodule.pri is not fatal any more
(like for qconfig.pri), to save the pointless effort of ensuring that it
exists.
Change-Id: I07625b60c4f2e27b21206b2c16d24ab111737395
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
when it comes to compiler flags (be it warnings or include paths), it
doesn't matter whether we building/using bootstrap libraries, but
whether we are actually cross-building.
amends c55bdc271f and d8be8110a.
Change-Id: Idf988107e9cccc486672c0ee70dc9bdf8eab9d8c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
"simctl list devices" has changed output format in
Xcode 8 beta to include additional information placed
inside parentheses for each device. And this confuses the
scripts we use to parse and find UUIDs.
Instead of making the inline scripts even longer and more
complex, this patch will factor most of it out to a separate
perl script that reads out device information on json format
and parses the UUID.
Change-Id: I3cd4dc276ecda030fda1932073c8bf1e0bc85deb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
It results in passing an option on the command line that e.g. the
QCommandLineParser doesn't understand.
Change-Id: Ied08c930fab479b6432f025dfe861bdf22c513e6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This fixes errors linking against Qt when built as shared libraries and
with bitcode enabled (default on tvOS and watchOS).
Change-Id: I3eb3bb0b9615e0bc41e43ffae8645248dbf803c6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Mike Krus <mike.krus@kdab.com>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
It's optional but default in Xcode, and will probably become required
Change-Id: I6917a9cf15b48dbaee57f1a92ea47d68fb3c253a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Mike Krus <mike.krus@kdab.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
- remove the unconditional CONFIG+=c++11 from default_pre.prf, so the
change actually has any effect
- fix up the description fields somewhat
this amends 091df96fb8, which was rushed in without maintainer review.
Change-Id: I88b859d6e2f0fe3d6a4771afe464a7c445e7b47b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
These are not meant to be overwritten by command line defines
anyway. Bad things could happen if they are not in sync with
the values in the pro files.
If you want to change them, reconfigure Qt.
Change-Id: Ic456e54b97e6909f01a4f4be33e3d7e2b2571e80
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Defining QT_OPENGL_ES_2 would only lead to conflicts with defines from
qconfig.h.
QT_OPENGL_ES_2_ANGLE also moves to the .pri.
QT_OPENGL_ES_2_ANGLE_STATIC is not used and is removed altogether.
Change-Id: I614fb00525ac696e066ac8328bb9bf61fca08a01
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Use the new qtConfig macro in all pro/pri files.
This required adding some feature entries, and adding
{private,public}Feature to every referenced already existing entry.
Change-Id: I164214dad1154df6ad84e86d99ed14994ef97cf4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
privateFeature would add QT_NO_FEATURE to the DEFINES in the private
.pri file, which was somewhat inelegant.
Additionally, it would add the feature to the _public_ QT_CONFIG
variable, which was plain wrong.
Replace the implementation with the one just introduced for
publicFeature, with the difference that the features are written to the
private files instead.
As this entirely disposes of the old system, all usages in the project
files need to be replaced atomically as well.
Change-Id: I506b5d41054410659ea503bc6901736cd5edec6e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Added a qtConfig(feature) function to qmake, and a QT_CONFIG(feature)
macro. These can safely check whether a certain compile time feature of
Qt is enabled or not.
For this to work the feature has to have a publicFeature or
privateFeature output in the configure.json file.
In pro files, please use the qtConfig(feature) test function
instead of checking contains(QT_CONFIG, feature), as the latter
will be unreliable with the upcoming modularization (it requires a
load(qt_module_config) before doing any such checks). Note that
feature names are now lowercase, and identical (except for hyphens
versus underscores currently) in the pro and c++ files.
This makes the logic easier to follow, as we avoid all double negations,
and most importantly, QT_CONFIG and qtConfig are implemented in a
way that you'll get a build error for a mistyped or non-existent
feature. This will also prevent accidental use of a widget feature
in gui in the future.
This gives us complete symmetry between the handling in pro and
c++ files.
Change-Id: I60404f97953724e639ffb6386cce2e8b1e4b735a
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Output the version as a define into the private config header as
a define using a hex number. Like that we can easily do version checks
on libraries using the QT_LIBRARY_VERSION(lib) and QT_VERSION_CHECK()
macros.
Change-Id: I6dc4ac6550886ca95c5542b6e75cd933ed079d76
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
this wasn't possible when these headers were still generated by syncqt,
as the targets may have been still missing at that time. however, as we
do that now with qmake, forwarding the timestamps is perfectly possible,
and is consistent with what syncqt itself does for "regular" headers.
the immediate problem this solves: when the early creation of the
forwarding headers in qtbase.pro is removed, they get created only when
corelib.pro is processed. their timestamps would be after the timestamps
of the already built bootstrapped libraries. if now the project files of
these libs get re-created, qmake's not conditional-aware dependency scan
would add these headers to the libs' deps, thus causing them to be
re-built. the re-built tools would in turn cause all mocs and thus all
libraries to be re-built. this would be particularly problematic if it
happened between 'make' and 'make install' due to another bug ...
Change-Id: I8d597f1f925369d93aaf3cc6c02e954eeae003a4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
this switches all instances of LIBS[_PRIVATE] += -lfoo where a config
tests exists for foo.
this removes some code duplication between tests and project files (in
case of conditionals), and ensures that the projects always actually use
the libraries configure has found.
Change-Id: Ia7e80c8db5f329290c7f1a4e03a8bf78882a687e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Adding an entry that represents an external library to the
QT_USE[_PRIVATE] variable will cause qmake to lookup the
required compiler/linker flags from the configuration system,
and add them to the module that is being compiled.
Change-Id: I309aa2749ddf4fab13ab8fdd26e8ab2123719ea8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
cleaner, and covers windows as well.
Change-Id: I0e884909a3f49610fab750ba1ef6112f43e5d5d1
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
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>
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>
So far we only had support for locating executables. Also
support locating header files and libraries.
Change-Id: Ib2a83e8338d2da975204089d84c608061a081f29
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
