Next: Sources, Previous: Build system regeneration, Up: Other Automake features [Contents][Index]
As a developer it is often painful to continually update the Makefile.am whenever the include-file dependencies change in a project. Automake supplies a way to automatically track dependency changes.
Automake always uses complete dependencies for a compilation,
including system headers. Automake’s model is that dependency
computation should be a side effect of the build. To this end,
dependencies are computed by running all compilations through a
special wrapper program called depcomp
. depcomp
understands how to coax many different C and C++ compilers into
generating dependency information in the format it requires.
‘automake -a’ will install depcomp
into your source
tree for you. If depcomp
can’t figure out how to properly
invoke your compiler, dependency tracking will simply be disabled for
your build.
Experience with earlier versions of Automake (see Dependency Tracking Evolution in Brief History of Automake) taught us that it is not reliable to generate dependencies only on the maintainer’s system, as configurations vary too much. So instead Automake implements dependency tracking at build time.
Automatic dependency tracking can be suppressed by putting
no-dependencies in the variable AUTOMAKE_OPTIONS
, or
passing no-dependencies as an argument to AM_INIT_AUTOMAKE
(this should be the preferred way). Or, you can invoke automake
with the -i option. Dependency tracking is enabled by default.
The person building your package also can choose to disable dependency tracking by configuring with --disable-dependency-tracking.
Dependency tracking is performed as a side-effect of compilation.
Each time the build system compiles a source file, it computes its
list of dependencies (in C these are the header files included by the
source being compiled). Later, any time make
is run and a
dependency appears to have changed, the dependent files will be
rebuilt.
Automake generates code for automatic dependency tracking by default, unless the developer chooses to override it; for more information, see Dependencies.
When configure
is executed, you can see it probing each
compiler for the dependency mechanism it supports (several mechanisms
can be used):
~/amhello-1.0 % ./configure --prefix /usr … checking dependency style of gcc... gcc3 …
Because dependencies are only computed as a side-effect of the
compilation, no dependency information exists the first time a package
is built. This is OK because all the files need to be built anyway:
make
does not have to decide which files need to be rebuilt.
In fact, dependency tracking is completely useless for one-time builds
and there is a configure
option to disable this:
Speed up one-time builds.
Some compilers do not offer any practical way to derive the list of
dependencies as a side-effect of the compilation, requiring a separate
run (maybe of another tool) to compute these dependencies. The
performance penalty implied by these methods is important enough to
disable them by default. The option --enable-dependency-tracking
must be passed to configure
to activate them.
Do not reject slow dependency extractors.
See Dependency Tracking Evolution in Brief History of Automake, for some discussion about the different dependency tracking schemes used by Automake over the years.
Next: Sources, Previous: Build system regeneration, Up: Other Automake features [Contents][Index]