Our first attempt at automatic dependency tracking was based on the
method recommended by GNU
make. (see Generating Prerequisites Automatically in The GNU
This version worked by precomputing dependencies ahead of time. For each source file, it had a special .P file that held the dependencies. There was a rule to generate a .P file by invoking the compiler appropriately. All such .P files were included by the Makefile, thus implicitly becoming dependencies of Makefile.
This approach had several critical bugs.
gcc. (A limitation, not technically a bug.)
make. (A limitation, not technically a bug.)
make. For instance, ‘make clean’ would cause all the dependency files to be updated, and then immediately removed. This eagerness also caused problems with some configurations; if a certain source file could not be compiled on a given architecture for some reason, dependency tracking would fail, aborting the entire build.
automaketo generate a Makefile that did not have automatic dependency tracking (and that was thus portable to any version of
make). In order to do this portably, Automake had to scan the dependency files and remove any reference that was to a source file not in the distribution. This process was error-prone. Also, if ‘make dist’ was run in an environment where some object file had a dependency on a source file that was only conditionally created, Automake would generate a Makefile that referred to a file that might not appear in the end user’s build. A special, hacky mechanism was required to work around this.
The code generated by Automake is often inspired by the Makefile style of a particular author. In the case of the first implementation of dependency tracking, I believe the impetus and inspiration was Jim Meyering. (I could be mistaken. If you know otherwise feel free to correct me.)