diff options
author | Evan Wilde <etceterawilde@gmail.com> | 2023-01-02 06:40:14 (GMT) |
---|---|---|
committer | Evan Wilde <etceterawilde@gmail.com> | 2023-01-21 18:37:09 (GMT) |
commit | bf3a8ef6d59946a5479b5d8eb554cdb05e56bb2b (patch) | |
tree | 5bec68b2996018e4fdfd135ff90ab8fb4ddc2f46 /Tests/LinkLineOrder/NoDepZ.c | |
parent | d0b469b7e03e0d902b3d8e2bf2f0b694438f0bf1 (diff) | |
download | CMake-bf3a8ef6d59946a5479b5d8eb554cdb05e56bb2b.zip CMake-bf3a8ef6d59946a5479b5d8eb554cdb05e56bb2b.tar.gz CMake-bf3a8ef6d59946a5479b5d8eb554cdb05e56bb2b.tar.bz2 |
Ninja: Swift: Add dependency edge to swiftmodule file
Swiftmodules act like headers for Swift, but are generated by the
compiler while building the module. Unlike headerfiles in a pure C/C++
world, where the compiler generates the appropriate depfile. We don't
have We're
already adding the swiftmodule as an output from swift-linked targets,
but aren't using that on inputs.
This dependency edge is most important for static libraries in
incremental builds. Suppose we have two static libraries, A, and B, and
an executable E. B "links" against A, and E links against B. In a C/C++
environment, the library link dependency edge will run from E to both A
and B, but there won't be an edge from B to A. If A is changed, the only
way this should affect B is if the public interface changes, in which
case, the headers will also change. The dep file contains the header
link, so Ninja will rebuild B when appropriate. With Swift in an
incremental build, B sees the order-dependency on A, but A already
exists. If A is changed in a way that changes the public interface, the
swiftmodule will change, but since we don't track it, we don't rebuild
B, resulting in the final executable to fail to link.
Diffstat (limited to 'Tests/LinkLineOrder/NoDepZ.c')
0 files changed, 0 insertions, 0 deletions