# FILE\_SET is a game changer, my design works but looking for feedback

**URL:** https://discourse.cmake.org/t/file-set-is-a-game-changer-my-design-works-but-looking-for-feedback/15882
**Category:** Community
**Created:** [October 20, 2026, 5:27pm UTC](https://discourse.cmake.org/t/file-set-is-a-game-changer-my-design-works-but-looking-for-feedback/15882 "2026-10-20T17:27:52Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![Jeff\_K](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/j/ce73a5/32.png) [@Jeff\_K](https://discourse.cmake.org/u/Jeff_K)
#### Post date: [October 20, 2026, 5:27pm UTC](https://discourse.cmake.org/t/file-set-is-a-game-changer-my-design-works-but-looking-for-feedback/15882/1 "2026-10-20T17:27:52Z")

</div>

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](https://github.com/JeffKarling/Target_Layout)  
Documentation: [Target Layout](https://jeffkarling.github.io/Target_Layout/)