One interesting thing here is that the decision of whether or not to
track system dependencies ends up going into the cache key for a
swiftmodule built from a parseable interface, because it affects that
module's up-to-date check. If we didn't include
-track-system-dependencies in the cache key, we could end up tracking
system dependencies for some modules but not others in the same build.
There's a bit of a bug here where they're /not/ honored if the
top-level invocation isn't tracking /any/ dependencies, but given
how uncommon this flag is in practice that's probably okay for now.
Still TODO: honor this for -build-swiftmodule-from-parseable-interface
as well. That's currently not tracking dependencies at all and it
probably should.
And fix the error message printing while I'm at it.
I don't have a public test for this at the moment, but an Apple-
internal tool will use it. I hope to upstream that tool in the future.
A ‘forwarding module’ is a YAML file that’s meant to stand in for a .swiftmodule file and provide an up-to-date description of its dependencies, always using modification times.
When a ‘prebuilt module’ is first loaded, we verify that it’s up-to-date by hashing all of its dependencies. Since this is orders of magnitude slower than reading mtimes, we’ll install a `forwarding module` containing the mtimes of the now-validated dependencies.
Otherwise, the top-level compilation gets the benefit of the prebuilt
cache path, but the sub-invocations for swiftinterfaces that /do/
need to be compiled do not.
