Update our cflags and lflags with the ones found in android.toolchain.cmake
Fixes: QTBUG-73274
Change-Id: Id9fd9bf04df959239abd3100090a1485e872b2f0
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Header files of modules that specify generated_privates are usually
not yet available at qmake-time. Thus, the installation rule must not
check for the file's existence.
Change-Id: Ifc7ff95422912d255744c9006382ff181176ae77
Fixes: QTBUG-71340
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This makes it much easier to have the version information set for an
Android APK without having to manually modify the AndroidManifest.xml
each time.
[ChangeLog][Android][qmake] Can now set the version name and code for
Android using ANDROID_VERSION_NAME and ANDROID_VERSION_CODE respectively
in the pro file.
Change-Id: Ie6813bc3a7444f7baa5e772b93bc2695d9b81e57
Done-with: Markus Maier <markus.maier@rosenberger.de>
Reviewed-by: Markus Maier <markus.maier@rosenberger.de>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Also catches some more variants of SDK mismatch, such as Xcode not
being installed at all, or the SDK missing.
Change-Id: I184aaa571ef0ea722ca64c54f665462dabc17533
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
If configure is called with -continue, it should not stop processing
command line arguments after encountering an invalid one.
Example:
configure ... -continue -quack -no-feature-gui
would ignore everything after -quack.
Change-Id: Ia5f0cb13414c9c0c7246ff0c72f8e935fe6dca3c
Fixes: QTBUG-72912
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
...and yield a warning that -skip has no effect in a qtbase build.
This is consistent with configure's help output and enables us to
always pass "-skip qtwhatnot", whether we're calling top-level or
qtbase configure.
Change-Id: Ie5b0791a6000d1d78b1367658ad86a92b2ec6a6a
Fixes: QTBUG-71253
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Integrity assembler doesn't understand NEON assembly statements.
Compiler enables _ARM_NEON_ and _ARM_NEON to indicate that NEON
intrinsics are available. _ARM_NEON_ and _ARM_NEON needs to be
disabled to skip handwritten assembly code paths in Qt.Auto-
vectorization is enabled without the flags enabled.
Task-number: QTBUG-72716
Change-Id: I84cfbf98bd2af47740a79f4b300c1801017ee22c
Reviewed-by: Tuukka Turunen <tuukka.turunen@qt.io>
Reviewed-by: Kimmo Ollila <kimmo.ollila@qt.io>
Reviewed-by: Timo Aarnipuro <timo.aarnipuro@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
After 521a85395d configure doesn't find
OpenGL libraries from QMAKE_LIBDIR, hence we use QMAKE_LIBDIR_OPENGL_ES2
and QMAKE_LIBDIR_EGL instead.
Task-number: QTBUG-73136
Change-Id: Iaeac46000c5d684f601741cbef91ce745ceb4ea2
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
This has been removed in emscripten compler version 1.38.23 and will
cause building apps to fail.
Change-Id: I7e58053ce06053f6f1d577377b503cabb035bb58
Fixes: QTBUG-73143
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
That target is added unconditionally at the end of windeployqt.prf.
Fixes: QTBUG-73018
Change-Id: I8d29691c30df64bf5383daa10e169985d47592f2
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The @executable_path relative framework directory is one step below
the executable, as in:
Foo.app/Contents/Frameworks
not:
Foo.app/Contents/MacOS/Frameworks
The former is what Xcode defaults to for new projects.
Change-Id: Id08f3f1d80f1c84d76fb71676c5df4a3a6b3da36
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Qt couldn't be configured with -system-zlib on macOS, because qmake
failed to find "/usr/lib/libz.dylib".
The library path is something along the lines of
"/Applications/Xcode.app/.../MacOSX10.14.sdk/usr/lib" which doesn't
contain "libz.dylib". But it contains "libz.tbd", which is a YAML-file
pointing to "/usr/lib/libz.dylib". One can pass the absolute path to
this tbd file to the linker, which will then pick up
"/usr/lib/libz.dylib".
Introduce a new variable QMAKE_EXTENSIONS_AUX_SHLIB, which is a list
of auxiliary extensions for shared libs, and add the "tbd" extension
to it on macOS.
Change-Id: I083b79a69d00232e35f9d6164ffa86cb473f1742
Fixes: QTBUG-72745
Fixes: QTBUG-72964
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Linking with a framework suffix to pick up the debug version of
libraries doesn't work as long as the dependencies picked up from prl
files are not rewritten to also include the suffix. The result is that
we end up loading both release and debug versions of the Qt libraries.
Use the target environment (target_wrapper.sh) to set the image suffix
instead, which means 'make check' will automatically work.
Change-Id: I60b0840760f68e579c270245d394e1dd609a0ebb
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Mimicking the approach from testlib_defines.prf, DEFINES containing a path
surrounded by quotation marks have to be handled differently for Visual
Studio projects.
Change-Id: I26f6a45d4df154f599e8be15b3aa3905cf703a1f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
while it's legacy and should not be used (use QMAKE_USE+=egl instead),
it shouldn't be broken nonetheless.
amends 310bf3f57c.
Fixes: QTBUG-72564
Change-Id: Id6a070a4653dc1182a6b4d75af027a6ee6cbacae
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Rolf Eike Beer <eb@emlix.com>
rather than reproducing vcvarsall.bat's functionality as hard-wired code
in the nmake generator, just invoke the actual script from
toolchain.prf. this is much easier, more future proof, and - critically
- makes the detected variables available to configure's new library &
header search facilities.
[ChangeLog][Important Behavior Changes][qmake][WinRT] Cross-builds will
now ignore pre-set values of %INCLUDE% and %LIB% when building target
executables. If necessary, use configure's -I and -L switches when
building Qt, and pass QMAKE_INCDIR and QMAKE_LIBDIR on qmake's command
line when building own projects.
Change-Id: I36f53e8880d6523f3f6f7a44d40d87d04bd06854
Reviewed-by: Thomas Miller <thomaslmiller91@gmail.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
swap the order of compiler version detection and default path detection.
this keeps a subsequent commit smaller, which introduces a dependency
between the two.
Change-Id: I2d4cbee1fd3555411c18833bbee0201c994a9942
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
There's no need to check the SDK at the root exclusive-build Makefile,
we can leave it to the individual build passes where the SDK variable
is available.
Fixes: QTBUG-72449
Change-Id: Ic829babf4c76e6d20812de0b94120199ebfb300c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
... and use that to inline the xlocalescanprint test.
Change-Id: I0973133d7f9ecc9a38b70dc4b83df174a35b2b1f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
this is implemented by means of (multiple) inheritance, which applies
specifically only to the inlined source and header list, but not to
library sources or dependencies.
Change-Id: I8f1d5b34d1d2d12e39225dc50357ad6ec648c6b6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
it works without it, but technically speaking it's undefined behavior.
Change-Id: Icdcdd5b923ce4cecd9dc9e75f9d5d66d0fa8a032
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
while the command line doesn't actually permit it (that can be
re-evaluated separately), derivatives of the inline source type may want
to inject additional paths, as is the case with opcua.
the incdir field supports multiple entries without additional action.
Change-Id: I3860ca1fc8fab25c04eb63bdb2f855b77ff3b9a4
Reviewed-by: Rainer Keller <Rainer.Keller@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
this allows compile-testing the specified headers with no further tests.
Change-Id: I268ff328deee221d9b92386fe2bd133b19a6f8e2
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
like all qt_*.prf files (exceptions prove the rule), the configure
system counts as private api.
Change-Id: Iea3057445e430029ecd8449e604e2d5c499ae10a
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
To enable LTCG, clang-cl.exe need "-flto" instead of "-GL". But if you
enabled LTO, the lib tool will have to change to "llvm-lib.exe" and the
link tool also need to change to "lld-link.exe", because msvc linker
will see these lib files as corrupted files. Leave QMAKE_LFLAGS_LTCG
empty because lld-link doesn't need any additional parameters.
Fixes: QTBUG-72402
Change-Id: Ia34d98bd1ad919d542ea3eac83944bf8c40ce0cd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
in addition to the actual library resolution, also resolve the headers
belonging to the library, to validate the include path, and possibly
ensure that the right version of the library is present.
the "include" entries were moved out of the "test" objects, and renamed
to "headers". this cleanly permits libraries without compile tests.
the headers were not put into the sources, because the variance among
the includes is generally orthogonal to the variance among the
libraries.
note that this - like the library resolution - provides no support for
darwin frameworks. consequently, the opengl libraries are excluded from
the conversion on darwin.
similarly, wasm is excluded (centrally), because emcc is magic and would
need advanced wizardry to be dealt with.
Change-Id: Ib390c75371efa2badcfec9b74274047ce67c3e5a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
fbbe8aba9d introduced a check for
MSVC_VER to qmake, which is not set in win32-clang-msvc,
causing the build to fail:
Mkspec does not specify MSVC_VER. Cannot continue.
Unable to generate output for: .../config.tests/verifyspec/Makefile
Extract a minimal msvc-based-version.conf which determines
MSVC_VER from QMAKE_MSC_VER for win32-clang-msvc and win32-icc.
Task-number: QTBUG-63512
Change-Id: Ia6de8c4b1aae2ae1962cf4e60e3e6d51fdbbbabe
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
... when QMAKE_DEFAULT_{INC,LIB}DIRS cannot be determined.
it would have been nicer to actually persist empty results, but cache()
won't do that, and fixing it doesn't seem worth the effort now.
Change-Id: I95d5645e40a0da572f0def16462703373eaeb804
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
these cannot be possibly correct, and might mislead.
Change-Id: Ie10531807978def04768e2429304949415cafb2a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
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>
