|
Unix Programming - make: Automating Your Recipes - Generating Makefiles
Generating Makefiles
One of the subtle advantages of Unix
make over the dependency databases built
into many IDEs is that makefiles are simple text files — files
that can be generated by programs.
In the mid-1980s it was fairly common for large Unix program
distributions to include elaborate custom shellscripts that would
probe their environment and use the information they gathered to
construct custom makefiles. These custom configurators reached absurd
sizes. I wrote one once that was 3000 lines of shell, about twice as
large as any single module in the program it was configuring —
and this was not unusual.
The community eventually said “Enough!” and various
people set out to write tools that would automate away part or all of
the process of maintaining makefiles. These tools generally tried to
address two issues:
One issue is
portability
. Makefile
generators are commonly built to run on many different hardware
platforms and Unix variants. They generally try to deduce things about
the local system (including everything from machine word size up to
which tools, languages, service libraries, and even document
formatters it has available). They then try to use those deductions to
write makefiles that exploit the local system's facilities and
compensate for its quirks.
The other issue is
dependency
derivation
. It's possible to deduce a great deal about the
dependencies of a collection of C sources by analyzing the sources
themselves (especially by looking at what include files they use and
share). Many makefile generators do this in order to mechanically
generate make dependencies.
Each different makefile generator tackles these objectives in a
slightly different way. Probably a dozen or more generators have
been attempted, but most proved inadequate or too difficult to drive
or both, and only a few are still in live use. We'll survey the major
ones here. All are available as open-source software on the
Internet.
Several small tools have tackled the rule automation part of the
problem exclusively. This one, distributed along with the X windowing
system from MIT, is the fastest and most useful and comes
preinstalled under all modern Unixes, including all
Linuxes.
makedepend takes a collection of
C sources and
generates dependencies for the corresponding .o
files from their #include directives. These can be
appended directly to a makefile, and in fact makedepend is defined to
do exactly that.
makedepend is useless for anything
but C projects. It doesn't try to solve more than one piece of the
makefile-generation problem. But what it does it does quite
well.
makedepend is sufficiently documented
by its manual page. If you type man makedepend at a
terminal window you will quickly learn what you need to know about
invoking it.
Imake was written in an attempt to
mechanize makefile generation for the X window
system. It
builds on makedepend to tackle both the
dependency-derivation and portability problems.
Imake system effectively replaces
conventional makefiles with Imakefiles. These are written in a more
compact and powerful notation which is (effectively) compiled into
makefiles. The compilation uses a rules file which is system-specific
and includes a lot of information about the local environment.
Imake is well suited to X's
particular portability and configuration challenges and universally
used in projects that are part of the X distribution. However, it has
not achieved much popularity outside the X developer community. It's
hard to learn, hard to use, hard to extend, and produces generated
makefiles of mind-numbing size and complexity.
The Imake tools will be available on
any Unix that supports X, including Linux. There has been one heroic
effort [DuBois] to make the mysteries of
Imake comprehensible to non-X-programming
mortals. These are worth learning if you are going to do X
programming.
autoconf was written by people who
had seen and rejected the Imake
approach. It generates per-project configure
shellscripts that are like the old-fashioned custom script
configurators. These configure scripts can
generate makefiles (among other things).
Autoconf is focused on portability
and does no built-in dependency derivation at all. Although it is
probably as complex as Imake, it is much
more flexible and easier to extend. Rather than relying on a
per-system database of rules, it generates
configure shell code that goes out and searches
your system for things.
Each configure shellscript is built from a
per-project template that you have to write, called configure.in. Once generated, though, the
configure script will be self-contained and can
configure your project on systems that don't carry
autoconf(1)
itself.
The autoconf approach to makefile
generation is like imake's in that you start by writing a makefile
template for your project. But autoconf's
Makefile.in files are basically just makefiles
with placeholders in them for simple text substitution; there's no
second notation to learn. If you want dependency derivation, you must take
explicit steps to call
makedepend(1)
or some similar tool — or use
automake(1).
autoconf is documented by an on-line
manual in the GNU info format. The source scripts
of autoconf are available from the FSF archive site, but are
also preinstalled on many Unix and Linux versions. You should be able to
browse this manual through your Emacs's help system.
Despite its lack of direct support for dependency derivation,
and despite its generally ad-hoc approach, in mid-2003
autoconf is clearly the most popular of the
makefile generators, and has been for some years. It has eclipsed
Imake and driven at least one major
competitor (metaconfig) out of use.
A reference, GNU Autoconf, Automake and
Libtool is available [Vaughan]. We'll have
more to say about autoconf, from a slightly
different angle, in Chapter17.
automake is an attempt to add
Imake-like dependency derivation as a layer
on top of
autoconf(1). You
write Makefile.am templates in a broadly
Imake-like notation;
automake(1)
compiles them to Makefile.in files, which
autoconf's configure scripts then operate
on.
automake is still relatively new
technology in mid-2003. It is used in several
FSF
projects but has not yet been widely adopted elsewhere. While its
general approach looks promising, it is as yet rather brittle —
it works when used in stereotyped ways but tends to break badly if you
try to do anything unusual with it.
Complete on-line documentation is shipped with
automake, which can be downloaded from the
FSF archive site.
[an error occurred while processing this directive]
|