# collect source lists

**URL:** <https://discourse.cmake.org/t/collect-source-lists/15459>\
**Category:** Code\
**Created:** [January 14, 2026, 11:30pm UTC](https://discourse.cmake.org/t/collect-source-lists/15459 "2026-01-14T23:30:33Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![JBB\_NOAA](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/j/f19dbf/32.png) [@JBB\_NOAA](https://discourse.cmake.org/u/JBB_NOAA)\
**Post date:** [January 14, 2026, 11:30pm UTC](https://discourse.cmake.org/t/collect-source-lists/15459/1 "2026-01-14T23:30:33Z")

</div>

The documentation for file GLOB says  
"

Note

We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate. The `CONFIGURE_DEPENDS` flag may not work reliably on all generators, or if a new generator is added in the future that cannot support it, projects using it will be stuck. Even if `CONFIGURE_DEPENDS` works reliably, there is still a cost to perform the check on every rebuild."

I am editing a CMake build that does exactly that. Is there a recommended alternative approach?

Thanks,

Jerome

---

<div class="post-metadata">

**Author:** ![Angew](https://discourse.cmake.org/user_avatar/discourse.cmake.org/angew/32/229_2.png) [@Angew](https://discourse.cmake.org/u/Angew)\
**Post date:** [January 15, 2026, 7:49am UTC](https://discourse.cmake.org/t/collect-source-lists/15459/2 "2026-01-15T07:49:10Z")

</div>

The recommended approach is to list the source files explicitly instead of relying on globbing. That way, you have to modify the CMakeList file when adding a new source, which causes CMake to re-run on next build, guaranteeing that the file will be picked up correctly.

If the file list is too long and you do not want to clutter your CMakeList with it, you can move the source definition (e.g. a `target_sources()` call) into a separate `*.cmake` file and `include()` that.

---

<div class="post-metadata">

**Author:** ![JBB\_NOAA](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/j/f19dbf/32.png) [@JBB\_NOAA](https://discourse.cmake.org/u/JBB_NOAA)\
**Post date:** [January 15, 2026, 3:50pm UTC](https://discourse.cmake.org/t/collect-source-lists/15459/3 "2026-01-15T15:50:36Z")

</div>

Thanks!

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [February 9, 2026, 2:14am UTC](https://discourse.cmake.org/t/collect-source-lists/15459/4 "2026-02-09T02:14:20Z")

</div>

For more background, see:

> [@Add GLOBBING support to target\_sources?](https://discourse.cmake.org/t/add-globbing-support-to-target-sources/3749):
>
> Currently here are 2 common patterns in our CMake codebase. Since we really like the safe globbing functionality added in 3.13. What is already possible # SAFE GLOBBING! :D file(GLOB\_RECURSE sources CONFIGURE\_DEPENDS \*.cpp \*.h) target\_sources(foobar PRIVATE ${sources}) # or # SAFE GLOBBING! :D file(GLOB sources CONFIGURE\_DEPENDS \*.cpp \*.h) target\_sources(foobar PRIVATE ${sources}) Proposal I think it would be great to add this support inside target\_sources # To get recursive behavior specif…

> [@Is GLOB still considered harmful with CONFIGURE\_DEPENDS?](https://discourse.cmake.org/t/is-glob-still-considered-harmful-with-configure-depends/808/2):
>
> The check costs depend on the platform (and probably generator too). I don’t know of the performance costs, but that’s because I personally find that even if it were performant, there’s at least one issue that I run into often enough to make it not worth it. I still highly discourage globbing for the reason that files may appear in your source tree that you do not intend to build. The main case I’ve run into is that during conflict resolution in git, the other versions of the file(s) in conflic…