Update CMP0215 to avoid attempting to iterate through the flags
looking for `-emit-module-path` ins the user-specified flags. We don't
do this anywhere else in the code. The existing implementation didn't
handle correctly parsing the flag so `-I blah/my-emit-module-path/` and
`-Xcc -emit-module-path ...` would both trigger it, result in the
compiler not emitting any module. Furthermore, it didn't include the
user-specified module path as part of the build graph resulting in an
incorrect build graph that would never resolve.
The only two appropriate layouts for the module are either the flat
binary module file with the name `<module-name>.swiftmodule`, or the
nested form with
`<module-name>.swiftmodule/<module-triple>.swiftmodule`. The noted
Swift-Syntax situation passes the explicit `-emit-module-path` to get to
the latter form. This form is automatically emitted by CMake when
CMP0195 is `NEW`, removing the need for the flag. The Swift project
generally recommends the nested directory structure since it gathers all
of the generated interface outputs from the compiler (textual swift
interfaces, swiftdoc, sourceinfo, and the binary swiftmodule file) in a
single place, and since it uses the module triple in the filename,
cleanly allows fat mach-o binaries on Apple platforms.
Fixes: #28021
Since commit b6367f723b (Swift/Ninja: Emit modules separately from
compilation, 2026-04-10) the .swiftmodule output moved from the
compile edge to a separate emit-module edge. The link edge does not
depend on the emit-module output, so ninja never runs the emit-module
edge when no other target in the build imports the module (e.g.
install-only targets).
Store the declared .swiftmodule output path during Swift object
statement generation and add it as an implicit dependency of the link
edge.
Issue: #27748
Evan Wilde
Roman Lavrov