automake: Wildcards
1
1 27.3 Why doesn’t Automake support wildcards?
1 ============================================
1
1 Developers are lazy. They would often like to use wildcards in
1 ‘Makefile.am’s, so that they would not need to remember to update
1 ‘Makefile.am’s every time they add, delete, or rename a file.
1
1 There are several objections to this:
1 • When using CVS (or similar) developers need to remember they have
1 to run ‘cvs add’ or ‘cvs rm’ anyway. Updating ‘Makefile.am’
1 accordingly quickly becomes a reflex.
1
1 Conversely, if your application doesn’t compile because you forgot
1 to add a file in ‘Makefile.am’, it will help you remember to ‘cvs
1 add’ it.
1
1 • Using wildcards makes it easy to distribute files by mistake. For
1 instance, some code a developer is experimenting with (a test case,
1 say) that should not be part of the distribution.
1
1 • Using wildcards it’s easy to omit some files by mistake. For
1 instance, one developer creates a new file, uses it in many places,
1 but forgets to commit it. Another developer then checks out the
1 incomplete project and is able to run ‘make dist’ successfully,
1 even though a file is missing. By listing files, ‘make dist’
1 _will_ complain.
1
1 • Wildcards are not portable to some non-GNU ‘make’ implementations,
1 e.g., NetBSD ‘make’ will not expand globs such as ‘*’ in
1 prerequisites of a target.
1
1 • Finally, it’s really hard to _forget_ to add a file to
1 ‘Makefile.am’: files that are not listed in ‘Makefile.am’ are not
1 compiled or installed, so you can’t even test them.
1
1 Still, these are philosophical objections, and as such you may
1 disagree, or find enough value in wildcards to dismiss all of them.
1 Before you start writing a patch against Automake to teach it about
1 wildcards, let’s see the main technical issue: portability.
1
1 Although ‘$(wildcard ...)’ works with GNU ‘make’, it is not portable
1 to other ‘make’ implementations.
1
1 The only way Automake could support ‘$(wildcard ...)’ is by expanding
1 ‘$(wildcard ...)’ when ‘automake’ is run. The resulting ‘Makefile.in’s
1 would be portable since they would list all files and not use
1 ‘$(wildcard ...)’. However that means developers would need to remember
1 to run ‘automake’ each time they add, delete, or rename files.
1
1 Compared to editing ‘Makefile.am’, this is a very small gain. Sure,
1 it’s easier and faster to type ‘automake; make’ than to type ‘emacs
1 Makefile.am; make’. But nobody bothered enough to write a patch to add
1 support for this syntax. Some people use scripts to generate file lists
1 in ‘Makefile.am’ or in separate ‘Makefile’ fragments.
1
1 Even if you don’t care about portability, and are tempted to use
1 ‘$(wildcard ...)’ anyway because you target only GNU Make, you should
1 know there are many places where Automake needs to know exactly which
1 files should be processed. As Automake doesn’t know how to expand
1 ‘$(wildcard ...)’, you cannot use it in these places. ‘$(wildcard ...)’
1 is a black box comparable to ‘AC_SUBST’ed variables as far Automake is
1 concerned.
1
1 You can get warnings about ‘$(wildcard ...’) constructs using the
1 ‘-Wportability’ flag.
1