Hi all,
I’m an engineer looking for feedback. About a year ago implications of FILE_SET clicked for me - eliminating artificial include/ src/ split trees and messy target_include_directories boilerplate become a eye opener. It lead me to a design where the component (.cpp / .hpp / test.cpp) literally is the CMake target. I use the design in production and it is flying making me evangelical (which is reflected in my documentation), but that prob also means i don’t see the trees due to the forest. So I am looking for feedback.
The design rule is simple: One directory = one component = one CMake target. The directory name, CMake target name, translation unit, public header, namespace, and test all share a single identical name.
Specific concerns:
Auto-registration vs. Explicit registration:
Currently, srcTargets/CMakeLists.txt uses file(GLOB … LIST_DIRECTORIES true CONFIGURE_DEPENDS) to discover component subdirectories automatically. Is CONFIGURE_DEPENDS reliable enough in larger team workflows across diverse build tools (Ninja, VS, Xcode), or is a explicit add_subdirectory() calls better?
FILE_SET adoption and packaging:
The layout relies heavily on FILE_SET TYPE HEADERS so headers stay co-located with their .cpp while maintaining clean #include <text/text.hpp> syntax. For downstream distribution (install(TARGETS … FILE_SET … EXPORT …)), but is there any subtle gotchas with FILE_SET in fine-grained layouts?
Target granularity at scale:
In small-to-medium projects, 1:1 component-to-target mapping feels clean and compiler-enforced. For those of you managing hundreds or thousands of components, what are your thoughts on this level of granularity versus grouping components into coarser compilation units? Does link overhead or build-graph size become a bottleneck?
I appreciate any critique / recommendations.
Repository: GitHub - JeffKarling/Target_Layout: Target Layout is a project template demonstrating modern CMake C++ project setup. · GitHub
Documentation: Target Layout