The swift toolchain leaves output files untouched
if there are no meaningful input changes; without
restat, this causes ninja to needlessly rebuild
targets that are not actually out-of-date
Fixes: #25496
Swift compile commands need to have all source files in the module
specified in the compile command or LSP systems will report errors on
missing types that are defined in other source files in the same module.
Issue: #25491
The CMP0157 old behavior omitted the output-file-map after the Swift
build split because we stopped calling `EmitSwiftDependencyInfo` when we
could not split the build because we didn't call
`WriteObjectBuildStatement`. If we can't split the build, then we still
need to include the OFM information to not break incremental builds.
In commit 878ae03832 (macOS: IMPORTED framework: Honor SYSTEM target
property in all cases, 2023-08-27, v3.28.0-rc1~162^2) we broke support
for `IMPORTED_LOCATION_<CONFIG>` without `IMPORTED_CONFIGURATIONS`.
Previously it worked if the importing project's configurations match the
set of `IMPORTED_LOCATION_<CONFIG>` properties set. Fix that case.
Fixes: #25506
Issue: #25515
Splitting the Swift build into an object build and a separate link step,
instead of building and linking in one step. The immediate benefit is
LSP support because we are able to emit compile-commands for Swift files
now. Additionally, it is possible to specify flags to the compile step,
enabling folks to emit C and C++ headers from their Swift builds for
C/C++ interop, without needing custom commands. Eventually, this gives
us a path toward working object libraries.
Object Libraries:
- Object libraries don't work today because CMake doesn't emit targets
for object libraries into the Ninja build file.
- tl;dr: Object libraries work if they aren't WMO. Still need work to
make WMO'd object libraries work.
Object libraries still don't completely work with this patch because,
while we emit the targets, the `TARGET_OBJECTS` generator expression
expansion has a separate mechanism for determining what the names of
the objects are based on the input source files, so targets that
depend on an object library built with a whole-module optimization
will depend on objects based on the name of the source file instead
of the actual emitted object file.
These features require being able to accurately model wholemodule builds
though, because we actually need to track object files and WMO affects
what objects are emitted. For that, we require CMP0157 use the NEW
policy. When it's OLD, we have to fall back on the old behavior and
cannot provide object libraries or the compile-commands for LSP.
Issue: #25308
