Next: , Up: Rationales   [Contents][Index]

I.1 Why doesn’t Automake support wildcards?

Developers are lazy. They would often like to use wildcards in Makefile.ams, so that they would not need to remember to update Makefile.ams every time they add, delete, or rename a file.

There are several objections to this:

Still, these are philosophical objections, and as such you may disagree, or find enough value in wildcards to dismiss all of them. Before you start writing a patch against Automake to teach it about wildcards, let’s see the main technical issue: portability.

Although ‘$(wildcard ...)’ works with GNU make, it is not portable to other make implementations.

The only way Automake could support $(wildcard ...) is by expanding $(wildcard ...) when automake is run. The resulting Makefile.ins would be portable since they would list all files and not use ‘$(wildcard ...)’. However that means developers would need to remember to run automake each time they add, delete, or rename files.

Compared to editing Makefile.am, this is a very small gain. Sure, it’s easier and faster to type ‘automake; make’ than to type ‘emacs Makefile.am; make’. But nobody bothered enough to write a patch to add support for this syntax. Some people use scripts to generate file lists in Makefile.am or in separate Makefile fragments.

Even if you don’t care about portability, and are tempted to use ‘$(wildcard ...)’ anyway because you target only GNU Make, you should know there are many places where Automake needs to know exactly which files should be processed. As Automake doesn’t know how to expand ‘$(wildcard ...)’, you cannot use it in these places. ‘$(wildcard ...)’ is a black box comparable to AC_SUBSTed variables as far Automake is concerned.

You can get warnings about ‘$(wildcard ...’) constructs using the -Wportability flag.

Next: , Up: Rationales   [Contents][Index]