We’re deploying a CMake build system with the Ninja generator for a large, mostly Fortran code base, and trying to understand why we don’t seem to get the build parallelism we are expecting. We suspect that, when library B depends on library A, the build is waiting for all of A to be compiled and archived before starting to compile anything in B, which is often a stricter dependency than necessary.
Poking through history I found a merge request https://gitlab.kitware.com/cmake/cmake/-/merge_requests/430/ which addresses this very issue, except it contains a comment that it couldn’t be completely fixed for Fortran. Has any further work been done on this? What’s the current status?
No further work has been done. For such dependencies to be broken, it must be known that there are no exported modules from library A that are used in library B. Since this depends on content, it has to be pessimized without an explicit flag in the CMake code saying “there are no modules, so drop the dependency” (which would break in the build later if one does appear). This work has not been done (and is probably only the beginning of pulling a long thread).
But if there are modules from library A that are used in library B, can’t that just be captured by generating explicit dependencies of the form “Bfoo.o depends on Abar.mod” wherever needed? Or does CMake not generate dependencies with that level of granularity?
CMake does not support declaring that kind of dependency in CMake code; it discovers it during the build, so the dependency has to be kept for now. I think some of this kind of investigation will end up being necessary for C++20 modules (as they will put C++ back into this situation where inter-library dependencies have to be pessimized). Fortran can use whatever that solution is too I imagine.