When building in a unix style build system (i.e. msys), QMAKE_DIRLIST_SEP
is a colon, not a semicolon. Thus, always split the incoming string
(after the fixup regex) using semicolons on windows.
This matches the code for gcc, further up, which does:
equals(QMAKE_HOST.os, Windows): \
paths = $$split(line, ;)
else: \
paths = $$split(line, $$QMAKE_DIRLIST_SEP)
Change-Id: I6a0175f9d14ae9ca188553483b7868f0549c784a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
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>
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>
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>
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>
... instead of only toolchain.prf.
the license check could go haywire, and everything else that file does
is meaningless in configure context anyway.
Task-number: QTBUG-63452
Change-Id: I5e31c87fe717fda40978c0317556070637e537e2
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
SYSTEM is used for system() calls, while SHELL is used in the target
Makefiles.
Task-number: QTBUG-62985
Change-Id: Ia75d3939c59c98699359421166433e8b4a6ee35e
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
We obviously should check the variable we're about to get the data from.
Amends 1216f596bd.
Change-Id: Ibe87138b9c9aa99837b4fbf3769cd26ca1aaacb9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
it's unclear where to look for the error when the message talks about
'g++' when '${CROSS_COMPILE}g++' would have been expected. help it by
saying whether it was supposed to be the host or target compiler.
this also centralizes the error emissions in a function.
Change-Id: I454c6ff7c0e7dd945dcee0de01e2818caeeb7409
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
With 4183475080, Qt fails to build if
qmake is unable to detect the compiler's default include and
library search paths. Clang on non-Darwin systems was missing working
code for the detection.
Unlike GCC, Clang on its own does not print the library search paths
when called with the -v option.
On Darwin, the -Wl,-v option will reach ld64, which will print those paths.
However, neither GNU ld nor gold will print anything useful with just
-v. GNU ld has a --verbose option that does print some search paths, but
those are not the ones used when ld is invoked (via collect2) by GCC or
Clang, so it can't be used.
To make Clang print its library search paths one can use
-print-search-dirs, which however doesn't print include search paths. So
amend the existing code in order to make a second call to clang on
non-Darwin systems. This second call is used for library path detection,
and fixes the build on non-Darwin (tested on Linux).
Change-Id: Ic858f908ee1a2e0eb307abb074daee0ded38abd5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
uikit/sdk.prf replaces QMAKE_MAC_SDK_PATH with a make expansion of that
variable, which of course does not work when we use the contents
directly.
amends 6d5489f5d.
Task-number: QTBUG-61690
Change-Id: Id77dff8ee7d737dd35f74cc7d39faaa50b4b1ab9
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Adds a bit of extra safeguard to ensure we don't accidentally fall into
the generic unix isEmpty(QMAKE_DEFAULT_{INC,LIB}DIRS) code-paths.
Change-Id: Id760b32cd29cb2b9db1390c174e1637e2dddaabc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
We need to actually run the linker, otherwise clang will just
run the preprocessing step as we asked for. We build as a shared
library to not have to provide a main() function.
Change-Id: Ied34757bb5c43a862bf2d9778340c497b93d572f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The configure-time detection (cxx11default) isn't enough if the compiler
can be changed. This is especially necessary if Qt is compiled with a
compiler that defaults to >= C++11 (e.g., GCC 6) and then the user
selects a compiler another compiler (e.g., Clang) via -spec option. In
that case, we'd miss adding the -std=c++11 or -std=gnu++11 option to the
command-line, causing the compilation to fail.
As a nice side-effect, even moc without moc_predefs.h will now get the
__cplusplus setting.
Task-number: QTBUG-58321
Change-Id: I74966ed02f674a7295f8fffd14a8be35da9640e1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
The compiler command line used to populate QMAKE_DEFAULT_INCDIRS must
include the sysroot in order to generate the correct paths list.
This fixes a regression introduced in afd8263 which in turn attempted to
fix an earlier regression making it impossible to override the
deployment target in user project files.
Task-number: QTBUG-58325
Change-Id: I93e6b7ef90b2744dd2f03c77da31c692cb194976
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
there isn't a point to determining the values separately if they are
actually the same things.
Change-Id: I74cd2bf39e96d559630709559602c234c38b0c47
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
note that in principle this leaves room for a race condition, as the
first project to determine the host config is not going to be the
top-level one.
in qtbase and qtdeclarative, this is naturally serialized via the common
bootstrapped libraries (bootstrap resp. qmldevtools). activeqt, qt3d,
qtscxml, and qtwayland all build only one bootstrapped tool each.
qtwebengine makes a fake host build to create files for gyp/gn; the
convert_dict tool is declared a host tool, but isn't actually built when
x-building anyway, and even if, it's serialized on the former. qttools
needs explicit serialization, though. no other host builds exist within
qt as of now.
Task-number: QTBUG-58126
Change-Id: I81a02a2d98f2bfe5d6aaa51119d5e7919549f119
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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 hardcoding the compat version in the spec, run cl.exe (which
needs to be around anyway) to figure out what version to emulate.
Change-Id: I6eae97fe9a78f8e340ecdabcdc0d48738497c6d2
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
this makes it consistent with the determination of the default
include/library paths. this makes sense, as it's possible to switch the
sdk/toolchain after building qt (within reason).
a side effect of this change is that for compilers which emulate other
compilers, both the real and the emulated version are now made
available.
Change-Id: Icfcc672c0d2e3d1b5e622993c366063d70ad327c
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
the code got factored out to an own toolchain.prf file, which is
load()ed from default_pre.prf, so no change at first.
however, on mac, we shadow toolchain.prf, and make it load() sdk.prf
first.
a side effect, it has become harder to disable the use of an sdk
altogether: putting CONFIG-=sdk into a project file or the qmake
command line has no effect now. instead, it's possible to put it into
.qmake.{conf,cache}.
to make it simpler again, it's conceivable to finally add qmake -pre,
which would allow setting variables before default_pre.prf is executed.
take 2: there was nothing wrong with the original patch, but in 5.8,
CONFIG+=simulator_and_device moved from qconfig.pri to various prf files
that would do it according to the simulator_and_device configure
feature, which would be way too late for the "pulled ahead" sdk.prf
loading. as simulator_and_device is now gone entirely, it is safe to
re-apply this patch (mostly) as-is.
Task-number: QTBUG-56144
Change-Id: I6cf484982eaed8af39f7a539c60f5a087a299914
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
