summaryrefslogtreecommitdiffstats
path: root/Tests/LinkLineOrder/NoDepZ.c
diff options
context:
space:
mode:
authorEvan Wilde <etceterawilde@gmail.com>2023-01-02 06:40:14 (GMT)
committerEvan Wilde <etceterawilde@gmail.com>2023-01-21 18:37:09 (GMT)
commitbf3a8ef6d59946a5479b5d8eb554cdb05e56bb2b (patch)
tree5bec68b2996018e4fdfd135ff90ab8fb4ddc2f46 /Tests/LinkLineOrder/NoDepZ.c
parentd0b469b7e03e0d902b3d8e2bf2f0b694438f0bf1 (diff)
downloadCMake-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