Description
I also confirmed this result on rules_swift. For example, app.swift is a module, and it depends on another module called module_b.swift.
remark: Incremental compilation: Enabling incremental cross-module building
remark: Incremental compilation: May skip current input: {compile: app.swift.o <= app.swift}
remark: Incremental compilation: Invalidated externally; will queue {compile: app.swift.o <= app.swift}
remark: Incremental compilation: Queuing (initial): {compile: app.swift.o <= app.swift}
remark: Found 1 batchable job
remark: Forming into 1 batch
remark: Adding {compile: app.swift} to batch 0
remark: Forming batch job from 1 constituents: app.swift
remark: Starting Emitting module for srcs_ios_lib
remark: Finished Emitting module for srcs_ios_lib
remark: Starting Compiling app.swift
remark: Finished Compiling app.swift
However, this is actually a very bad experience in the daily process. Even if some private function are added to module b, the change of .swiftmodule still causes the dependency tree to be recompiled. Although private_deps can partially solve the greater damage caused by dependency propagation, the experience is still not good when there are large-scale module changes.
Do we have any other solutions? Can we rely on library_evolution and not pass .swiftmodule, but just reference and compile through .swiftinterface? I see that compile_config.bzl doesn't implement this and always passes .swiftmodule. I want to know if this is feasible?