| |
Unix Programming - make: Automating Your Recipes - Utility Productions
Utility Productions
Some of the most heavily used productions in typical makefiles
don't express file dependencies at all. They're ways to bundle up
little procedures that a developer wants to mechanize, like making
a distribution package or removing all object files in order to do
a build from scratch.
|
Non-file productions were intentional and in there from day
one. ‘Make all’ and ‘clean’ were my own
conventions from earliest days. One of the older Unix jokes is
“Make love” which results in “Don't know how to
make love”.
|
|
| --
Stuart Feldman
|
|
There is a well-developed set of conventions about what utility
productions should be present and how they should be named.
Following these will make your makefile much easier to understand
and use.
-
all
-
Your all production should make every
executable of your project. Usually the all
production doesn't have an explicit rule; instead it refers to all of
your project's top-level targets (and, not accidentally, documents
what those are). Conventionally, this should be the first production in
your makefile, so it will be the one executed when the developer types
make with no argument.
-
test
-
Run the program's automated test suite, typically consisting of
a set of unit tests[137] to find regressions, bugs, or other deviations
from expected behavior during the development process. The
‘test’ production can also be used by end-users of the
software to ensure that their installation is functioning correctly.
-
clean
-
Remove all files (such as binary executables and object files)
that are normally created when you make all. A
make clean should reset the process of building the
software to a good initial state.
-
dist
-
Make a source archive (usually with the
tar(1)
program) that can be shipped as a unit and used to rebuild the program
on another machine. This target should do the equivalent of depending
on all so that a make dist
automatically rebuilds the whole project before making the
distribution archive — this is a good way to avoid last-minute
embarrassments, like not shipping derived files that are actually
needed (like the flat-text README in
fetchmail, which is actually generated from an
HTML source).
-
distclean
-
Throw away everything but what you would include if you were
bundling up the source with make dist. This may be
the the same as make clean but should be included
as a production of its own anyway, to document what's going on. When
it's different, it usually differs by throwing away local
configuration files that aren't part of the normal make
all build sequence (such as those generated by autoconf(1);
we'll talk about autoconf(1) in Chapter17).
-
realclean
-
Throw away everything you can rebuild using the makefile. This
may be the same as make distclean, but should be
included as a production of its own anyway, to document what's going
on. When it's different, it usually differs by throwing away files
that are derived but (for whatever reason) shipped with the project
sources anyway.
-
install
-
Install the project's executables and documentation in system
directories so they will be accessible to general users (this
typically requires root privileges). Initialize or update any
databases or libraries that the executables require in order to
function.
-
uninstall
-
Remove files installed in system directories by make
install (this typically requires root privileges). This
should completely and perfectly reverse a make
install. The presence of an uninstall production implies a
kind of humility that experienced Unix hands look for as a sign of
thoughtful design; conversely, not having an uninstall production is
at best careless, and (when, for example, an installation creates
large database files) can be quite rude and thoughtless.
Working examples of all the standard targets are available for
inspection in the
fetchmail
makefile. By studying all of them together you will see a pattern
emerge, and (not incidentally) learn much about the
fetchmail package's structure. One of the
benefits of using these standard productions is that they form an
implicit roadmap of their project.
But you need not limit yourself to these utility productions.
Once you master make, you'll find yourself
more and more often using the makefile machinery to automate little
tasks that depend on your project file state. Your makefile is a
convenient central place to put these; using it makes them readily
available for inspection and avoids cluttering up your workspace with
trivial little scripts.
[an error occurred while processing this directive]
|
|
