As @jrose said in his WWDC talk, and we discussed further on Twitter, dependencies between targets/modules are course-grained, i.e. when changing something in a module, there might be unnecessary/unexpected recompilations of dependent targets happening.
This current state might hurt incremental compile times in cases where a project is split into multiple frameworks, and incremental changes are made on the source code of a framework during development.
Since splitting up an app into multiple frameworks is kind of a trend now (there are quite a lot of conference talks and articles on the topic of „Framework Driven Development“), how could incremental compilation behavior be improved? Is anything planned already?
1 Like
Hi Fabian,
Unfortunately, things are rather messy right now, because the Swift compiler actually takes on some of the job of managing dependencies. Within a module, the build system knows nothing of the intrafile dependencies, and it is all managed by Swift. Conversely, across a module it is managed by the build system.
llbuild was written so that there could be a single unified dependency graph (that could express more than just file dependencies), but we don’t use that yet in Swift. We also don’t have a plan for it.
I’m not sure if that helps, can you maybe clarify exactly what you were looking for?
Thank you for the information about the current state. I created this thread as I‘d like to follow discussions about improving incremental build time for projects divided into frameworks, and I could not find any. So I wasn‘t sure if there was active development going on, or even if the awareness about the issue was given.
For my own projects it means that I rather stop pulling out everything into a lot of frameworks, rather only a few for things that do not change often until the situation is improved.
1 Like
Looks like the „module stability“ project could help on this front, since as a side effect it could improve incremental build times: