Live implementations and build times

[wltrup]

Hi @tgrapperon, how does one go about separating the live from the non-live implementations of the dependencies in your library, insofar as compilation is concerned?

When I create my own dependencies, I generally create 2 modules, one for the non-live and one for the live, and the executables I build are the only targets that depend directly on the live ones. All the modules in my apps only import, and depend on, the non-live dependencies.

If I add your library as a dependency in a project, in the package manifest (all my apps are highly modularized and use SPM), won't the live parts of your library be compiled along with the non-live ones every time I make a fresh build of any of my modules (as opposed to an executable target)?

Now, I get that none of the current live implementations are costly in terms of build times but, as your library grows, it might add heftier code that might make build times an issue.

Thanks for the library and for considering my question(s).

[tgrapperon]

Hey @wltrup. I guess it is mostly because, as you mentioned, the live dependencies are very lightweight and build almost instantly. What's usually lengthy when building a dependency is building the dependency's dependencies! That is the Firebase SDK when bundling a dependency on this framework. The dependency itself usually takes very little time to build, but since you need the complete SDK implementation to build it, the live version overall can take a lot of time indeed.

Concerning the dependencies that ship with this library, they're currently all depending on system frameworks. These frameworks being part of the OS, it doesn't take much more time to build the liveValue version than the testValue, and that's why all dependencies are currently built in the same module. Furthermore, many dependencies are exposing types defined by these frameworks, so the system has to link them anyway.

This is also the route that swift-dependencies is following too. Of course, if it'd require it, a live version that would take a significant amount of time to compile would be extracted into its own module.

This furthermore avoids a pesky issue where Xcode prunes the liveValue if you don't refer to it explicitly. See pointfreeco/swift-composable-architecture#1640 for example. If the library should ship live values in separate modules, it should make sure to workaround this issue.

A clean build of the library currently takes a little more than 3s on my machine. I'll monitor this closely and take appropriate measures if needed. Quite ironically, what's taking the longest right now is resolving types in unimplemented test values!

[wltrup]

Hi Thomas, yes, that's what I was expecting. Thanks again.