[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Bugs
This approach had several critical bugs.
-
The code to generate the ‘.P’ file relied on
gcc
. (A limitation, not technically a bug.) -
The dependency tracking mechanism itself relied on GNU
make
. (A limitation, not technically a bug.) -
Because each ‘.P’ file was a dependency of ‘Makefile’, this
meant that dependency tracking was done eagerly by
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. - As dependency tracking was done as a pre-pass, compile times were doubled–the compiler had to be run twice per source file.
-
‘make dist’ re-ran
automake
to generate a ‘Makefile’ that did not have automatic dependency tracking (and that was thus portable to any version ofmake
). 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.