Xcode 10 ships version 921.0.1 of cctools, which otool is part of. The
defaults have changed in that version to no longer print verbosely
(symbolically), which we relied on. We now request it explicitly.
Change-Id: Ifbe0c97462b9f78cf128c820847eff9c72f17065
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Tim Blechmann <tim@klingt.org>
this considerably speeds up failures, as no doomed build is attempted,
and produces more reliable results, as no second lookup (which would be
subject to environment changes) is done any more during the build.
in principle, this also opens up possibilities like selecting specific
variants of dependencies, automatically extracting rpaths, etc.
qt_helper_lib.prf also needs to create fully resolved library names now.
Change-Id: I65f13564b635433030e40fa017427bbc72d1c130
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
amazingly enough, android has different sysroots for the compiler
(shared includes full of #ifdefs) and the linker (per-platform
libraries).
this patch supports only clang for non-darwin, which notably covers all
supported android ndks.
with this fixed, we also remove the hard-coded setting of
QMAKE_DEFAULT_*DIRS from the specs.
amends 353fb118c.
Change-Id: Ie0513de0f7123d7f5b8ca1ffcc72c017cddd126c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
When running configure on a Windows host, it would fail with the
error that the copy statement was invalid, due to the forward
slashes. This makes configure finish without errors.
Task-number: QTBUG-72000
Change-Id: Id315d7436bbbfd2cd5c5f2dfcfe0c3dc3b9e34c2
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
We have to check if the directory exists before calling mkdir or the test
will fail on every run but the first one.
Change-Id: I36f10cfc18b3cb99990dc96190349ee00a0c1c4e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Descriptions for WINRT_MANIFEST's subkeys are in the documentation.
Having a copy in the prf file is superfluous and is likely to run out
of sync at some point.
Change-Id: Icea49854981990139305f6dc4e73d1b9dcb01dd5
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
fix the plugin name (it was missing the leading 'q') and the name used
in configure (the latter making it unnecessary to mess with it in the
mkspec). the qt.prf override which forced linkage of the plugin is also
removed due to being completely redundant.
Change-Id: I94687a34a295c36754e36a298af902b656ba2ecc
Reviewed-by: Kyle Edwards <kyle.edwards@kitware.com>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
when building additional modules against an already installed qtbase,
$$[QT_INSTALL_PREFIX/get] is obviously the same as
$$[QT_INSTALL_PREFIX], so we would misdiagnose a non-prefix build.
instead, use the same condition as qt_build_config.prf (we cannot just
rely on what it sets, because in qtbase configure context it's evaluated
before we set up the paths).
Fixes: QTBUG-60541
Change-Id: I37be30e0e682ece76ed460a66f1984ee0fe2ed71
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
... for debugging purposes.
this needs to work in every configure run even though the options
(currently) come from qtbase's global scope. this is accomplished by
automatically injecting the test type dependencies declared in the
'builtins' scope (where they generally make no sense whatsoever, because
there are no tests there) into other scopes (the first one that has a
test of the particular type, specifically). we do that *after* the
scope's own test type deps, so it can do its custom stuff first (it can
explicitly activate the required features if it depends on some global
stuff).
Change-Id: I67317da1b55804d39458bdbcf13d39a3e57a13bf
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Removes need to manually build up qmake command line when there's
already a Makefile generated (from a recursive qmake_all run e.g.)
Instead, just run 'make xcodeproj'.
Change-Id: Ibe91b183230721a4bcaddfde53b623df00f7adb5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In NDKr18 Google removed GCC, most probably the massacre will not end
there and they will remove all GNU tools, so we need to start using LLVM
ones.
This patch still keeps the compatibility with GNU tools if the Qt was
built with android-g++ mkspec.
Change-Id: Ibe1979577e08ce63604d55fc5bbd5f64b3737675
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
[ChangeLog][qmake] Introduced the variables
WINDOWS_TARGET_PLATFORM_VERSION and
WINDOWS_TARGET_PLATFORM_MIN_VERSION for overriding the default values
of WindowsTargetPlatformVersion and WindowsTargetPlatformMinVersion in
Visual Studio project files.
The code to determine the default values is moved to qmake feature
files. A common/windows-desktop.conf file is introduced for variables
common to all non-UWP Windows mkspecs.
The package_manifest feature uses WINDOWS_TARGET_PLATFORM_VERSION as
default value for WINRT_MANIFEST.minVersion, and
WINDOWS_TARGET_PLATFORM_MIN_VERSION for
WINRT_MANIFEST.maxVersionTested respectively.
Task-number: QTBUG-53654
Change-Id: I251ec7f9b804c9bc9f7d571f5b43d52b2a2d99d3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
We need to support apps building against the 10.13 SDK, so that they
can opt out of dark mode and layer-backing. This does not mean we can't
require 10.14 to build Qt itself, but doing so should not require the
app to also build against the 10.14 SDK.
Change-Id: I53bd0fc8bf56c0be6614acec14d5173589e2620f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We want to inform the user when they have upgraded their Xcode version
and hence have a new SDK version, which requires a complete rebuild.
Explicit changes to the Xcode selection (be it via xcode-select or
$DEVELOPER_DIR) do not affect the existing build directory, so we must
record the Xcode selection inside the build to avoid false triggering.
Change-Id: I7d13da1232226712a4951e8a360cf4b634c6fa2f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Removing the extra space before -MT ensures that the vcxproj
generator gets valid input.
Change-Id: Iccf88c5fc4473db406d714b646185a4fb60a3418
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The dependencies.json file allows to tweak the list of imports the
module is depending on, so that types implicitly imported are not
listed twice.
Task-number: QTBUG-70264
Change-Id: I7a3800e5ea713a8aaae0cddbf4e1607f92c41497
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The correct name is c++1z. Anyhow, this is easy enough to get wrong,
so make sure CONFIG += c++17 works as well.
Task-number: QTBUG-67527
Change-Id: Iea26b18824b38b1b5170f85987cf5c750b8e10ab
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: André Hartmann <aha_1980@gmx.de>
This reverts commit 4bdd8d4eca.
It contains an error.
Change-Id: I51052029f001b9e82c2a53de15b4ba354aafdbae
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
In order to ship our own version of wayland.xml protocol code we need
to get rid of all includes of system versions of
wayland-client-protocol.h and wayland-server-portocol.h.
These were unfortunately included by wayland-client.h and
wayland-server.h and now can't be removed because of compatibility
issues. To solve this, wayland-client-core.h and wayland-server-core.h
can be included instead, which don't include any generated protocol
code. Again, due to compatibility concerns, wayland-scanner does not use
these versions unless invoked with --include-core-only, which is what
this patch fixes.
Task-number: QTBUG-70553
Change-Id: Icf7c870bd4d5bf891628cbddce2a9de3dda50164
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
This change applies to darwin. It adds each include path in the
QMAKE_DEFAULT_INCDIRS variable to the qdoc command line with the -I
flag for both the prepare and the generate phase. These include paths
provide access to the standard c++ and c headers, which clang needs
to see. This change should work on all platforms, but it increased
the qdoc warning count on the linuxsystem where it was tested, so
now it only applies to darwin.
Change-Id: I16e2e0d744e2cf68743dc12d39155dda2ece1536
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Add properties enabled_features and disabled_features the respective
library targets.
This makes it possible to query the enabled classes in dependent libraries
(for example, Qt for Python).
Add a test verifying whether the Open GL configuration is reflected
correctly in the feature properties to the existing test_opengl_lib
autotest.
Change-Id: I645c947073dbb36da3be81de6bc62ee0ba1e73d6
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
in non-prefix builds, the forwarding headers always end up in qtbase's
build dir, while the injected headers always live in the build dir of
the module they belong to. to deal with that, we now record the target
path relative to the module root dir instead of relative to the base
directory of the forwarding header itself.
Fixes: QTBUG-70056
Change-Id: Ic4346148a125b13e2610f6965cdf4f5266ac763e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Add QMAKE_QMLPLUGINDUMP_FLAGS variable that allows plugins to set
qmlplugindump options like -app, -noforceqtquick.
The naming follows the example of e.g. QMAKE_LRELEASE_FLAGS.
Task-number: QTBUG-70264
Change-Id: I1d11b7f3b03fab79ab9e06188cecf31650789302
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
We no longer support macOS 10.11, iOS/tvOS 10, or watchOS 3.
Change-Id: Ide03d8fac06185ef4162ba75ee54a0adf6916905
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Otherwise the SDK upgrade (or downgrade) may subtly and silently affect
the resulting binary, or if it results in build breaks, the user won't
know why.
We limit it to applications for now, as that's the point where it's
most important to catch the SDK upgrade, but technically we should
also do this for intermediate libraries. Doing it for everything
will likely incur a performance cost, so we skip that for now.
Change-Id: I8a0604aad8b1e9fba99848ab8ab031c07fd50dc4
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This is the squashed diff from wip/webassembly to dev.
Done-with: Peng Wu <peng.wu@intopalo.com>
Done-with: Sami Enne <sami.enne@intopalo.com>
Done-with: Morten Johan Sørvig <morten.sorvig@qt.io>
Started-by: Andrew Knight <andrew.knight@intopalo.com>
Change-Id: I6562433c0a38d6ec49ab675e0f104f2665f3392d
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
the global flags are deprecated in favor of per-library paths, but they
obviously should still work. but apparently no-one cares, because there
isn't even a bug report about it ...
amends 90eee08b3.
Change-Id: I85aee41ca11de1715d1c750ae8e663093e012fb7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
using qt$$MODULE isn't enough if the module is composed of submodules
which need the final module's headers, because that would require two
modules having the same module .pri file.
the first thought to fix this was to just use $$lower($$TARGET), but
that breaks for testlib (QtTest). while the config file name isn't
public api, it's included by a public header, so changing it is risky.
so instead stay with the original pattern, but make it explicitly
overrideable.
the cherry-pick is needed to support QtWebEngine 5.12 with Qt 5.11,
a requirement that was raised too late.
Change-Id: I758c46ed403620620d577ae16866ce751271b63e
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
(cherry picked from commit 95b0e4c956)
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
