Hacker News Reader

Comment by adrian_b | Hacker News Reader

Why would you want that?

In decades of programming in very varied environments I have never compiled any software project otherwise than by using globbing, so that I have never needed to waste time to write the name of any source file in a Makefile.

I have never seen any reason to do otherwise.

For instance, using special compilation flags for a certain source file, different from the others, is something that I consider a mistake. Whichever is the goal, it certainly can be achieved by other means (e.g. pragmas or attributes).

Moreover, the dependencies for any file must always be generated automatically, they must never be written explicitly, which removes the main reason why in bad Makefiles the names of the source files are written individually.

View on HN

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.

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.

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)

The problem with globbing is gratuitous matches. If a.cc depends on l.h and m.h, and b.cc only depends on m.h, doing a glob in the dependencies ( $(wildcard…) ) will unnecessarily rebuild b.o if l.h changes.

globs don't even prevent you from special casing one file to have different flags

True, but this should better be avoided, because in such cases reading the source files is not enough to understand what they do.

You must also be aware that they are compiled in a different way and you must search a frequently too big and obfuscated Makefile to discover which is the applicable compilation rule.

Unfortunately I have seen many projects that had used such tricks and it was always painful for maintenance to discover how they were supposed to work.

Reply on news.ycombinator.com