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