We build our project statically as well as dynamically, and we have noticed that when building with DLLs, the build is severely bottlenecked compared to its static lib OPTIMIZE_DEPENDENCIES — CMake 4.0.1 Documentation counterpart. Looking at the build under a dependency build graph like the GUI of IncrediBuild, you can see that the DLL build is waiting for Linker calls to happen and not compiling in the meantime.
We don’t actually need to wait for this. Each dll and pdb doesn’t need to exist until the project that depends on it is linking but instead cmake’s produced projects are causing the overall build to wait for those dlls before even beginning the compile step of the dependent jobs
CMake’s code model was developed prior to the existence of Ninja, at which time all build systems for which we had generators would build each target to completion before its dependents even start to build. No concurrency across dependent targets was achievable. Therefore custom commands in one target are allowed to generate files at build time that are consumed by other dependent targets, such as header files that may be included by the dependents’ sources. When the Ninja generator was introduced, we had to insert conservative dependency edges to implement this target ordering for compatibility with existing projects. Over time we’ve found ways to lift some of these dependencies.
OPTIMIZE_DEPENDENCIES was developed specifically with static libraries and object libraries in mind. Further work could probably extend some of its effects to shared libraries.