In commit 8d61294c3e (PCH: Mark CMake PCH source files as -x
<lang>-header, 2020-09-04, v3.18.3~14^2) we removed the explicit `-x
objective-c++` flag. This broke cases with custom source extensions.
Restore the explicit `-x objective-c[++]` flag and put it before the
`<FLAGS>` placeholder. The latter will contain the proper `-x
objective-c[++]-header` value and will override the `-x objective-c[++]`
value set before.
Fixes: #21234
The `-std:c11` option added by commit f7347f28c7 (MSVC: Record support
for C11 and c_restrict, 2020-08-09, v3.18.2~9^2) needs this flag table
entry to map in the VS IDE properly.
Issue: #21069
In commit 55196a1440 (MSVC: Use 'lib' instead of 'link /lib' to create
static libraries, 2020-01-10, v3.18.0-rc1~625^2) we changed CMake to use
lib instead of `link /lib` to create static libraries, but it didn't
search for `llvm-lib`. If you have `llvm-lib` but not `lib` (e.g. when
cross-compiling), when `CMakeFindBinutils` is invoked for the `C` and
`CXX` languages, `CMAKE_AR` is not found. When it's subsequently invoked
for the ASM language, `CMAKE_ASM_SIMULATE_ID` and
`CMAKE_ASM_COMPILER_FRONTEND_VARIANT` are not set (because
`CMakeDetermineASMCompiler` doesn't call `CMAKE_DETERMINE_COMPILER_ID`,
which sets those variables), so we go down the non-MSVC conditional and
set `CMAKE_AR` to a GNU-style `ar`, which of course does not understand
lib flags. Explicitly search for `llvm-lib` to avoid this situation.
A regex added by commit 6fdfe2428d (FindPython: enhance ABI checks
against include directory, 2020-09-02, v3.18.3~17^2) was missing a
backslash.
Fixes: #21223
d4390c13e9 Merge branch 'backport-3.17-check-compiler-flag-result'
d46590910c Check*CompilerFlag: Do not set result as a normal variable too
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alexander Grund <github@grundis.de>
Merge-request: !5250
Refactoring in commit cb984c6627 (Check*CompilerFlag: Modernize modules,
2019-12-09, v3.17.0-rc1~320^2) accidentally left the result set as a
normal variable in addition to as a cache entry. This is not specified
by the documentation, and is not the behavior in CMake 3.16 and below.
Fixes: #21207
a9fd3a10 addressed the scenario where the depending target is a
utility target, but not the scenario where the dependent target is
a utility target. Account for this scenario.
Also add a Qt-specific test case.
Fixes: #21118
Since commit 36ded610af (PCH: Generate sources during Compute step,
2019-10-05, v3.16.0-rc1~2^2) the source file lookup is done earlier than
before. Its parent commit f1fb63b306 (file(GENERATE): Create output
file structures even earlier, 2019-10-07, v3.16.0-rc1~2^2~1) prepared
for that. However, that commit did not account for generating and
using files in separate subdirectories.
Fix this by evaluating all generated files before adding automatic
files.
Fixes: #21144
GitLab 13.3 started creating MR pipelines in the parent project of a MR
from a fork, at least when the MR submitter is a developer in the parent
project. If the pipeline is associated with a MR, we should use the
corresponding rules regardless of which project hosts the pipeline.
AutoMoc uses the moc-emitted dependency file of Qt 5.15 to track
dependencies. Such a dependency may well live outside the project and
can vanish, for example when installing a new compiler version.
This situation was detected before, but merely a warning was issued.
Now, we're considering a generated file as out of date if a dependency
is missing and re-generate it.
We also have to remove the missing dependency from the ParseCache.
Otherwise the AUTOMOC target for all generators other than Ninja will
always be out of date.
The ParseCacheChanged flag had to be made atomic, because we're
potentially accessing it from multiple threads. The dependencies vector
itself is not vulnerable in this regard, because there's one vector per
file, and we're accessing exactly one ParseCacheT::FileHandleT per thread.
Fixes: #21136
Cristian Adam