`ExternalProject_Add_StepTargets` and `INDEPENDENT_STEP_TARGETS` have
some limitations and lack some sanity checks. They can cause confusing
build systems to be generated. The basic problems are:
* The notion of step independence is attached to the step target
rather than the step itself.
* The custom commands implementing the steps are duplicated in the
step targets and the primary targets. This can cause races.
It is also incompatible with the Xcode "new build system".
Fix this by introducing policy CMP0114 to change the way step target
dependencies are handled. Define independence from external
dependencies as a property of each individual step regardless of whether
there is a target for it. Add dependencies among the primary target and
the step targets such that each custom command only appears in one
target. When some steps are disconnected from the primary target, add
step targets for the steps commonly depended upon so that there is a
place to hold their custom commands uniquely.
Fixes: #18663
cf83758b24 Clang: Implement CMAKE_${LANG}_COMPILER_TARGET for all variants on windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5192
0512e94eb0 Tests: Fix PchInstantiateTemplates case on macOS with CMAKE_OSX_ARCHITECTURES
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5217
Previously when CMAKE_CROSSCOMPILING was ON we'd end up not setting the target
directory if the non-scattered one didn't exist.
Fix this by assuming a scattered installation if the target directory isn't set
after the crosscompiling logic.
bf88a94d88 ISPC: CompilerLauncher tests work properly with x86 builds
8de145cae1 ISPC: DynamicLibrary test now passes on windows.
a83521e082 ISPC: Use the `obj` file extension for objects on windows
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5213
Update the test added by commit 8c8f03422e (PCH: Template instantiation
support, 2020-08-28) to recognize flags on PCH files whose names include
the architecture. This occurs when `CMAKE_OSX_ARCHITECTURES` is set.
The MSVC linker needs to know what MSVC runtime a shared library
needs. ISPC objects don't have a '/DIRECTIVE' entry for the
MSVC runtime as they have no dependency on it. Therefore
we need to add a C or C++ source to each shared library so
the MSVC linker knows what runtime to embed
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.
Brad King