uses of this function (or the "files" stanza in configure.json) which
don't explicitly target windows don't specify the .exe extension, so we
need to add it automatically if it's missing.
Task-number: QTBUG-57436
Change-Id: I1994378399bc3466c32ee065e752516f42652975
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This patch reverts 388c4ef9f7. The reason is that it generates a symbol
(resource_init_function) based on the name of the pro-file. But if different
plugins are built from a pro-file with the same name, you end up linking in
many symbols with the same name as well. Which one that ends up being used at
runtime will typically depend on the linking order of the plugins.
This problem will happen if you build an app for iOS that uses both controls 1
and controls 2. In that case, both QML plugins are built from a "controls.pro"
file. At runtime, only one of the plugins will be imported correctly.
This patch therefore reverts 388c4ef9f7, but at the same time, to not
re-introduce the problem it fixed, we instead genereate both a debug and release
version of the plugin_resources.cpp file. That way we can still depend on the
TARGET variable for generating both the resource_init_function symbol and the
cpp file.
Fixes: QTBUG-62647
Fixes: QTBUG-71386
Fixes: QTBUG-72108
Change-Id: I3d8c53132458b30ed9f47a259f1f8e4fa4d44130
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
we already knew the dependencies (as they are declared in the json
files), but failed to export them in any way, which made linking against
statically built external deps which have deps in turn fail (unless the
project happened to pull in the dep anyway, as is the case with qtcore +
zlib).
the previous assumption was that the USE-able library objects would be
self-contained, but that is conceptually unclean. instead, properly
export the raw dependencies and resolve them only in qmake_use.prf.
note that pkg-config produces self-contained output, so we need to
actively subtract the dependencies we know.
Change-Id: I4b41a7efc05bbd309a6d66275d7557a80efd5af4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
clearly, nobody told clang that on windows you're supposed to use
semicolons instead of colons to separate elements of a path list ...
Fixes: QTBUG-72268
Change-Id: Ia7adc8de3bca586d4c15b069cb04e4cb647ae823
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This change reinstates functionality that was removed in
commit 102e1822ff. However, it
differs from the original implementation in several ways:
* It uses the QMAKE_PRL_LIBS variable, replacing whitespace with
semicolons, rather than using a dedicated QMAKE_PRL_LIBS_FOR_CMAKE
variable.
* More importantly, it parses the -L and -l flags and uses CMake's
find_library() command to look for the libraries in the specified
search paths, and then converts them to absolute paths. This is the
same approach that CMake's own FindPkgConfig module uses to find
libraries specified in this form. Any other flags not of the form
-L or -l (for instance, -s flags passed to Emscripten) are added to
the new INTERFACE_LINK_OPTIONS target property if the CMake version
is 3.13 or newer.
The original implementation of this functionality was removed because
of the lack of absolute library paths. At the time, it was believed
that qmake would have to be modified to do its own equivalent of
find_library() to get the absolute paths to the libraries. However,
the approach taken by FindPkgConfig has proven robust enough to be
used here, allowing CMake to find the absolute paths to the libraries
without having to modify qmake.
[ChangeLog][CMake] Added support for automatic linking of transitive
dependencies in static builds
Fixes: QTBUG-38913
Change-Id: I7d9cdb0d339c6ef697b04099d129481c770fc0fc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
note that pkg-config is a tad stupid: it won't tell us if the package is
built statically, but one needs to explicitly ask it to output
transitive deps for static packages. we can do that, as we resolve the
pkg-config output to actual libraries, so we know if they are static.
always asking it would print the transitive deps also if we found a
dynamically linked library, which would inappropriately extend the link
interface. the latter actually happens on windows (because we can't
easily tell apart real static libs from import libs), but that doesn't
matter, as under windows, the linker transitively resolves dlls anyway.
Change-Id: If1be3b3df476374d5c8e62f4b185477c988223b3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
Remove the option from msvc-desktop.conf, which duplicates
the /nologo option in idcidl.prf.
Fixes: QTBUG-72046
Change-Id: I906097e0611f4578c307616b3f9ebecdfc4d8812
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The failure mode of this behavior is worse than the surprises that the
non-explicit library dependency chain has, so it should be opt-in.
This reverts back to the behavior in Qt 5.11, but lets our tests
opt in to the feature.
Fixes: QTBUG-71724
Change-Id: Iede11f02d978b637324ddf71d29e7c99fe3ee99f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Eike Ziller <eike.ziller@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>
this is an exclusively user-controllable variable. the mkspec may provide
a default via QT_QPA_DEFAULT_PLATFORM when it deviates from the platform
default known to configure, and these specs actually already make use of
that.
Change-Id: I7531063d4c404ebed7b2cc1647c61626db30daef
Reviewed-by: Kyle Edwards <kyle.edwards@kitware.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@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>
these libraries are handled by the configure system. i presume this to
be an artifact of an early version.
Change-Id: Ieee0554163a9fe296097d09e60a70719beee97b4
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>
there is no reason whatsoever to ignore the variable if it's set to an
invalid value. also, it being empty would lead to a warning from qmake
since a while.
so instead check it for emptiness like every other variable, not for
file existence.
Change-Id: I1119f67520d2986811501cd3f223f8f4a87d067d
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@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>
Allows a qt build to be configured to target arm64 desktop apps cross
platform and build them with nmake.
Change-Id: I99fed12047b45a504a1644201bcc19b18c69f3e6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
AR and NM have different tools when LTCG is used,
override those also when cross compiling.
Fixes: QTBUG-71595
Change-Id: I5347bd1874688dd89395c50ff6dd08fb1c0ebab1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
