5 ms·

Globbing is possible but unwise. You do want a variable with an explicit list of sources, even while trying to make things as automatic and dynamic as possible.

adrian_b 3y ago
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.
- dataangel 3y ago
  globs don't even prevent you from special casing one file to have different flags
  - adrian_b 3y ago
    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.
- an_d_rew 3y ago
  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 3y ago
    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 3y ago
    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)
- deleted 3y ago
  [deleted]
- gumby 3y ago
  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.
dataangel 3y ago
Globbing is how you avoid pointless busy work. If there's a file in the directory that shouldn't be built, it shouldn't be there.
- adrian_b 3y ago
  When you want to exclude a file from compilation without deleting it, it is enough to change its extension, e.g. from ".c" to ".c_". Alternatively, you could move such a file to a subdirectory "Attic" or the like. Any of these solutions would ensure that globbing will no longer include that file in the list of source files, without needing to update any project configuration files.
- Brian_K_White 3y ago
  And nothing that shouldn't happen ever does. I guess you also include "." in $PATH, even roots.

adrian_b 3y ago

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.

dataangel 3y ago
globs don't even prevent you from special casing one file to have different flags
- adrian_b 3y ago
  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.
an_d_rew 3y ago
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 3y ago
  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 3y ago
  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)
deleted 3y ago
[deleted]
gumby 3y ago
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.

dataangel 3y ago

Globbing is how you avoid pointless busy work. If there's a file in the directory that shouldn't be built, it shouldn't be there.

adrian_b 3y ago
When you want to exclude a file from compilation without deleting it, it is enough to change its extension, e.g. from ".c" to ".c_". Alternatively, you could move such a file to a subdirectory "Attic" or the like. Any of these solutions would ensure that globbing will no longer include that file in the list of source files, without needing to update any project configuration files.
Brian_K_White 3y ago
And nothing that shouldn't happen ever does. I guess you also include "." in $PATH, even roots.