If the host architecture is different from -platform (canadian cross
build with -external-hostbindir) then we cannot use QMAKE_HOST.os to
deduce the executable extension for that platform, because this value
comes from the qmake binary that was pointed to by
-external-hostbindir.
Move the target name deduction mechanism to the actual configure test
.pro files to make sure the right scopes are available, and write the
deduced target name to a text file. That text file is read by
qtConfTest_architecture to get the right binary to analyze.
Fixes: QTBUG-77286
Change-Id: I68b844dd51dbfda6432a4b0dca6331899c82255f
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The host architecture detection binary's file extension is determined by
the host platform, not the target platform. Respect the host variable
that's set in configure.json.
This amends commit d9fb502.
Change-Id: I134cd7cf12d6a6fe458ac5e37c48dd311d6c4418
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Android is also unix, so can pick up the host 'arch' binary when
rerunning configure. This patch splits the names so we don't end up
confusing target and host binaries.
Task-number: QTBUG-76445
Change-Id: Ib65251a514e45ad8873f523d71c17e13e56ea58a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The --sysroot flag is added to QMAKE_CXXFLAGS by the gcc-sysroot
feature. However, when the makespec is reloaded, it can overwrite
QMAKE_CXXFLAGS.
Save QMAKE_CXXFLAGS before re-loading the mkspec and add it to the
value from the makespec, like we do for CONFIG.
Fixes: QTBUG-74326
Change-Id: Ie1fb713e2ffc9641d6db8c682bc5175581cd5b5f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
we don't check for licheck at this stage any more.
amends 60e56f167.
Change-Id: I4f8d57100796dce99bd605835b25a954a6359d30
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
It is not always easy to spot the compiler version in the build or
configure log, so report it explicitly to make our lives easier when
trying to figure out why a specific build might have failed.
Change-Id: I1c84199aad4a98a30b0b4c4fbf2554008dc3ba2d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The earlier NDK platforms do not support 64 bit architectures, so
configure would fail with a confusing message about problems in
the environment.
[ChangeLog][Android] Default to android-21 for arm64 builds instead
of failing.
Task-number: QTBUG-70280
Change-Id: Ib9846d6deee3d453fd4a17a3ae92306482d380ba
Reviewed-by: Simon Hausmann <simon.hausmann@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>
configure already does it for qt itself, so it's pointless to ever invoke
in default_pre.prf.
to make the exclusion work during the makespec reload during early setup,
we pull ahead the restoration of CONFIG, hoping it won't cause too many
side effects.
another change in qt5 will ensure that top-level builds are also covered.
finally, configure tests also need an explicit exclusion.
that way, attempts to re-configure build trees of commercial builds
after the day of the first configuration do not fail anymore.
Task-number: QTBUG-63452
Change-Id: I42264f64d7621784d4d67bde885a8e501f5ca413
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
9fde78269 fixed overrides for library definitions, but failed to fix
direct overrides of variables from mkspecs, like QMAKE_LIBS_OPENGL_ES2.
Task-number: QTBUG-69176
Change-Id: I818acf25f581903c323847382ec6baab38b64330
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
the sysroot flags need to be established even before setting up the
spec, because as soon as that happens, toolchain.prf will try to
determine the default paths and cache them.
this also fixes sysroot use in toolchain flag support tests, which run
(somewhat) independently from the toolchain setup.
Task-number: QTBUG-63483
Change-Id: I7be1540e766dac58fb16f63176aa8d2879b51ae0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
the callback is specific to qtbase/configure.json, so it belongs into
qtbase/configure.pri.
amends d90db0f136.
Change-Id: I905f985e2d3d2e42c4587cbacdea8dc3eb09a5be
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Do allow people to build from git using the Qt License Agreement 4.0.
The license agreement text is the same as in the installers, except
that some Unicode characters got normalized to their ASCII variants,
and things have been properly wrapped.
[ChangeLog][Licensing] The commercial preview license in the git
checkout has been replaced by the Qt License Agreement 4.0 text.
This makes it explicit that commercial customers of The Qt Company
can use the git version under commercial terms. However, support
is (still) only provided for builds from released branches of Qt.
Task-number: QTBUG-52222
Change-Id: I9e99b68e236a09610b798ba7a841e5a9d1ce6898
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
this de-noises the code somewhat, and makes it possible to eval() the
code generated by $$qtConfLibraryArgs(), which we want to do later.
Change-Id: Ib6101c6745101801e34f8fab1ad6651e624130c7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The configure unification accidentally changed it to /usr/local as used on
unix. Use C:/Qt again.
Task-number: QTBUG-61373
Change-Id: I758c639bdb07c97b55f990821e73a5135038f4a0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
... and make use of it.
it's a logical continuation of the 'arch' term, and will be used also in
qt3d's configure.
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I940917d6763842499b18fffd1514c96889a0cc63
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is necessary for WebEngine at configure time, to be able to query
which of the sanitizers was enabled in order to report unsupported
combinations.
Task-number: QTBUG-64726
Change-Id: I72f8efe4bed3e14114f885bdae16650f1f23b24b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The qtConfAddNotice was a typo, so this note was missing from
config.log and the build would fail with no explanation.
Change-Id: Iae22f92c1ba6bdf96d41a7cc608b9aedd6863b1f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Since the x86_simd/main.cpp file already has all the source for each and
every test anyway, just reuse it.
Change-Id: I938b024e38bf4aac9154fffd14f779f450827fb9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This has two main benefits:
1) introduces a qmake CONFIG we can use in .pro/.pri/.prf files
2) removes the need to keep an up-to-date list of which compilers
support the feature
The test is implemented as trying to compile every single SIMD test we
currently have, but without passing the -mXXX option. The reason for
trying all of them is that some people may have modified their mkspecs
to add -mXXX options or -march=XXX, which could enable the particular
feature we tried, resulting in a false positive outcome.
Change-Id: I938b024e38bf4aac9154fffd14f7784dc8d1f020
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
When QMAKE_* variable assignments were passed to the configure line
they would cause the current contents of the private pro output to be
overwritten. This would cause anything added to it before the QMAKE_*
variable assignments to be parsed to be lost.
Change-Id: Idcb8cad5f07cbb96b4da204384f5618b95b375b0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
there isn't really a point in doing strict shadow builds of them, and
it complicates stand-alone building of sub-projects (because it points
below the build root).
Task-number: QTBUG-58372
Change-Id: Ia3bde3826baac44749b27452fd4aeb9491ecb94e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... and rename those determined by toolchain.prf to QMAKE_* (this was
already the case for the newly introduced msvc and icc variables).
this restores the ability for user projects to query the toolchain qt
itself was built with, which is necessary for compatibility checks.
in fact, we may do such validation in toolchain.prf itself at a later
point.
Change-Id: I35f4c393c5e4e0fe987c0844714b7a8f8687c24e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
$$QMAKE_HOST.arch isn't very well defined for ia32 - on windows it's
x86, on linux it may be anything from i386 to i686. test for != x86_64
instead.
Task-number: QTBUG-61044
Change-Id: I8f3267b404fffbf479d87bee2e8ee8c6cd404b50
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
it can be (and usually is) empty (if the option was not used), which
would make it disappear from the command line.
Change-Id: Ic682e92a0d20cf849fade8449ebd79a5aa424d21
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Amend commit e6bf237669 to correctly
cache the abi in config.cache and set QT_BUILDABI to the correct target
ABI when cross-compiling.
Task-number: QTBUG-60441
Change-Id: I4ebfce9d6266be2a3225034fbf3aff08e7fdc5d5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
instead of calling eval() on the entire output, loop over it line by
line, because:
- the first line is a message, not a variable assignment
- eval() can process only one statement at a time
Task-number: QTBUG-60255
Change-Id: Idca652910c8f2c852372d486c51c8554bc708dcf
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This is needed to encode the correct ABI into the generated qml caches.
It is identical with the return value of QSysInfo::buildAbi().
Change-Id: I2d581b22326da4220f412ab4f517156f4ba31897
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
writing $$PWD (via $$QT_SOURCE_TREE) into the new bin/qt.conf would
potentially change the path compared to the value originally written by
the configure script, as $$PWD is canonicalized. this in turn would
break the magic for delaying the loading of toolchain.prf.
so instead just write out the perfectly fine current value of
$$[QT_INSTALL_PREFIX/src].
amends 169a40d51, thereby fixing 6834d0eec on windows.
Task-number: QTBUG-58816
Change-Id: Ibbd44df8f3c825a97d9f4acb869e44c93acb835b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
The minimum version of Xcode that we support is 5.1 (based on Clang 3.4)
Change-Id: I536c32a88bff44dab37afffd14a11f709fb25169
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
don't fail to set up cross_compile early enough. otherwise, we'd
populate the cache for target builds with data for the host.
amends 6b8666c7 and 5060740f.
conversely, pass on extra flags to configure tests when not cross
building.
amends d8be8110 (and 2c5eb3e6).
Task-number: QTBUG-58556
Change-Id: I531d71e06204a0b17ae6dabf017a52e0f2efd9a7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The patch fixes a number of bugs in code, and removes dead logic
clarifying that MIPS DSP, like ARM NEON, has no runtime detecton.
Change-Id: If2f4eea68da5b2eaa80b8e9c8258206d8c1b7173
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
in cross-builds, toolchain.prf was loaded before CROSS_COMPILE was set
up, leading to caching of possibly nonsensical values.
this change also necessitated that msvc-version.conf is loaded only when
toolchain.prf is, which is best done by loading the former from within
the latter. that seems quite appropriate in the first place.
Change-Id: I62577e827a75e335e03df016bd1aa1932643fd6c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
instead of forcing an early load and discarding its contents again
before they could cause harm, trick qmake into not loading it at all.
Change-Id: I672ca9de362b1f23bf5cfea007053570c8534fc6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
turns out that just appending builtin-qt.conf isn't a good idea:
executable-editing tools (objcopy, prelink, etc.) will happily drop the
"attachment".
a safe method would be adding a proper section to the executable, but
there doesn't appear to be an objcopy equivalent in msvc, and using
entirely different methods of embedding the file with different
toolchains seems like a rather bad idea.
so instead go back to the old method of building qmake with a generated
qconfig.cpp. of course, as said file is now created by qmake itself, we
have to compile qlibraryinfo.cpp a second time, and link a second qmake
executable.
Task-number: QTBUG-57803
Change-Id: I9e232693550aa870cec154e49cc06add13017cc2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
