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.
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.
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+.
Move it up the hierarchy from `cmLocalVisualStudio10Generator`.
Propagate contents from a target's dependencies as part of the main
target iteration logic instead of as part of the generator-specific
target generation.
