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
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
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
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
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.
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.
The same change was already made by commit f59c33a763 (VS: Generate a
custom command only in the least dependent target, 2018-03-23,
v3.12.0-rc1~171^2) for VS 10+.
