[an_d_rew]

Globbing means that the directory has to be scanned on every build

Once you start getting to multiple directories and recursive scans, the build time begins to grow enormously and usually unexpectedly.

Not a problem at all for small or even medium size projects on a fast machine.

But once you start building very large projects with multiple sub-projects, it generally slows the machine to a crawl on every build.

[adrian_b]

When the project is so big that this is a problem, you can make an additional make target, e.g. "make file_lists" that would use globbing and store the lists into a file that will be used by any other make commands.

The bigger a project is, the more important is to use only globbing and never write explicitly any file name lists.

However, I believe that this, the slowness of globbing for big directories, might be a strictly Windows-specific problem, if it exists. At least on Linux and with XFS (which has B-tree directories) I have never seen globbing to take any noticeable time, even on directories with ten thousand files or more, where it still appears to be instantaneous at the human reaction time scale.

There is no reason to ever do recursive scans. All the directories with source files of a project must be scanned to search for any source files located there, but only once.

[Brian_K_White]

I said unwise not inefficient.

Globbing is a security and reliability hole. You don't ever really know what got included or will get included, you just assume you do, and you are right only most of the time and only by luck not by actually ensuring it.

Saying things like "only the files I expect should ever be in this dir" is just wrong swiss cheese thinking. (you never said that, but another commenter essentially did)