Next: , Previous: , Up: Other Automake features   [Contents][Index]

13.6 Automatic dependency tracking

As a developer it is often painful to continually update the 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: , Previous: , Up: Other Automake features   [Contents][Index]