Is GLOB still considered harmful with CONFIGURE_DEPENDS?

Supposing you’re able to use the newest, shiniest version of CMake, what are the current drawbacks for globbing sources with CONFIGURE_DEPENDS?

The documentation reads:

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.

Emphasis mine. With which existing generators can CONFIGURE_DEPENDS be expected to work reliably? To work at all? Exactly how costly are those globbing checks that have to be performed on every rebuild?

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 conflict are named ${base}_${origin}_${pid}.${ext}, so if you try to build in the middle of a conflict, you’re going to glob up these files.

Another reason is that now the addition/removal of a file is not present in your build system diff, so tracking down “what did you change?” in debugging reported problems can be harder since there’s no evidence of accidentally added/removed files in a normal ${vcs} diff output.

1 Like