Why is cmake file GLOB evil?

问题:

The CMake doc says about the command file GLOB:

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.

Several discussion threads in the web second that globbing source files is evil.

However, to make the build system know that a source has been added or removed, it's sufficient to say

touch CMakeLists.txt

Right?

Then that's less effort than editing CMakeLists.txt to insert or delete a source file name. Nor is it more difficult to remember. So I don't see any good reason to advise against file GLOB.

What's wrong with this argument?

回答1:

The problem is when you're not alone working on a project.

Let's say project has developer A and B.

A adds a new source file x.c. He doesn't changes CMakeLists.txt and commits after he's finished implementing x.c.

Now B does a git pull, and since there have been no modifications to the CMakeLists.txt, CMake isn't run again and B causes linker errors when compiling, because x.c has not been added to its source files list.

回答2:

It's not inherently evil - it has advantanges and disadvantages, covered relatively well in this answer here on StackOverflow. But if you use it carelessly, you could end up ignoring dependency changes and requiring clean rebuilds of large parts of your codebase.

I'm personally in favor of using it - in smaller projects, or on certain subdirectories in larger ones - to avoid having to enter every file manually into the build files. Edit: My preference has changed and I currently tend to avoid it.