[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
27.3 Why doesn't Automake support wildcards?
Developers are lazy. They often would like to use wildcards in ‘Makefile.am’s, so they don't need to remember they have to update ‘Makefile.am’s every time they add, delete, or rename a file.
There are several objections to this:
-
When using CVS (or similar) developers need to remember they have to
run ‘cvs add’ or ‘cvs rm’ anyway. Updating
‘Makefile.am’ accordingly quickly becomes a reflex.
Conversely, if your application doesn't compile because you forgot to add a file in ‘Makefile.am’, it will help you remember to ‘cvs add’ it.
- Using wildcards makes easy to distribute files by mistake. For instance, some code a developer is experimenting with (a test case, say) but that should not be part of the distribution.
- Using wildcards it's easy to omit some files by mistake. For instance, one developer creates a new file, uses it at many places, but forget to commit it. Another developer then checkout the incomplete project and is able to run `make dist' successfully, even though a file is missing.
- Listing files, you control *exactly* what you distribute. If some file that should be distributed is missing from your tree, ‘make dist’ will complain. Besides, you don't distribute more than what you listed.
- Finally it's really hard to ‘forget’ adding a file to ‘Makefile.am’, because if you don't add it, it doesn't get compiled nor installed, so you can't even test it.
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
expending $(wildcard ...)
when automake
is run.
Resulting ‘Makefile.in’s would be portable since they would
list all files and not use ‘$(wildcard ...)’. However that
means developers need to remember they must run automake
each
time they add, delete, or rename files.
Compared to editing ‘Makefile.am’, this is really little win. 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 add support for this syntax. Some people use scripts to generated 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 need 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_SUBST
ed
variables as far Automake is concerned.
You can get warnings about ‘$(wildcard ...’) constructs using the ‘-Wportability’ flag.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |