b8ecd4df5f ExternalProject: Use CMP0114 NEW behavior with Xcode "new build system"
fe258f6382 Tests: Skip RunCMake.XcodeProject device cases for Xcode "new build system"
1c3d2d0951 Tests: Skip Qt*Autogen.MocSkipSource case for Xcode "new build system"
542884e527 Tests: Update RunCMake.XcodeProject cases for Xcode "new build system"
832a78be2d Tests: Update BuildDepends test for Xcode "new build system"
ff76c51ec3 Tests: Update RunCMake.file case with workaround for Xcode "new build system"
1806cdd17c Tests: Avoid duplicate custom commands for Xcode "new build system"
8d5f4c4db9 Xcode: Switch to the "new build system" for Xcode 12 and above
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5229
The ExternalProject module cannot be implemented in the Xcode "new build
system" without using CMP0114's NEW behavior. When configuring for that
build system, warn if the policy is not set to NEW and use NEW behavior
anyway.
The Xcode "new build system" selects different architectures for device
builds than the old build system does. Skip those tests on Xcode 12+
pending further investigation.
Issue: #21206
This test case enables AUTOMOC on the same sources in two separate targets.
This causes the `moc_*.cpp` generation custom commands to be added to multiple
`_autogen` targets, which is not allowed by the Xcode "new build system".
Skip the part of the test that triggers this problem for now.
Issue: #21205
Xcode somehow tracks what we're running inside a custom command,
so we cannot prevent it from regenerating the `noregen.h` header
even though we do not declare any dependencies of it.
Extend the `-T <toolset>` option to support a `buildsystem=` field with
the Xcode generator. Add a `CMAKE_XCODE_BUILD_SYSTEM` variable to
inform project code about the selected build system variant.
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 these commits:
* commit ab2276e6b9 (Utilities/Release: remove old macOS release script,
2020-09-16)
* commit 7670ba8b0a (Utilities/Release: Drop win{32,64} scripts in favor
of docker build, 2020-05-05, v3.18.0-rc1~203^2)
* commit 689fdbfc61 (Utilities/Release: Drop linux64 script in favor of
docker build, 2019-08-27, v3.16.0-rc1~184^2)
several scripts we once used for producing release binaries for
distribution on `cmake.org` are no longer needed.
Adds a set of sub commands to the string command for parsing JSON, the
JSON commands are: GET, TYPE, MEMBER, LENGTH, REMOVE, SET, and EQUAL.
Closes: #19501
`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
0512e94eb0 Tests: Fix PchInstantiateTemplates case on macOS with CMAKE_OSX_ARCHITECTURES
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5217
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
Old implementation uses involved Flex input management technique that
requires usage of obsolete YY_INPUT macro. This causes a lot of useless
allocations and byte-by-byte scanning. New implementation avoids those
hacks, it uses yy_scan_string() API to setup Flex input. Also it fixes
reporting of syntax error position and corresponding tests.
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
Do not attach a custom command to a target if it is already attached to one of
the target's dependencies. The command's output will be available by the time
the target needs it because the dependency containing the command will have
already been built.
This may break existing projects that do not properly mark non-created
outputs with the `SYMBOLIC` property. Previously a chain of two custom
commands whose intermediate dependency is not created would put both
commands in a dependent project's Makefile even if the first command is
also in its dependency's Makefile. The first command would run twice
but the build would work. Now the second command needs an explicit
`SYMBOLIC` mark on its input to tell CMake that it is not expected to
exist. To maintain compatibility with projects that left out the mark,
add a policy activating the behavior.
Brad King