automake-history: Dependencies As Side Effects
2.2 Dependencies As Side Effects
================================
Description
-----------
The next refinement of Automake's automatic dependency tracking scheme
was to implement dependencies as side effects of the compilation. This
was aimed at solving the most commonly reported problems with the first
approach. In particular we were most concerned with eliminating the
weird rebuilding effect associated with make clean.
In this approach, the '.P' files were included using the '-include'
command, which let us create these files lazily. This avoided the 'make
clean' problem.
We only computed dependencies when a file was actually compiled.
This avoided the performance penalty associated with scanning each file
twice. It also let us avoid the other problems associated with the
first, eager, implementation. For instance, dependencies would never be
generated for a source file that was not compilable on a given
architecture (because it in fact would never be compiled).
Bugs
----
* This approach also relied on the existence of 'gcc' and GNU 'make'.
(A limitation, not technically a bug.)
* Dependency tracking was still done by the developer, so the
problems from the first implementation relating to massaging of
dependencies by 'make dist' were still in effect.
* This implementation suffered from the "deleted header file"
problem. Suppose a lazily-created '.P' file includes a dependency
on a given header file, like this:
maude.o: maude.c something.h
Now suppose that you remove 'something.h' and update 'maude.c' so
that this include is no longer needed. If you run 'make', you will
get an error because there is no way to create 'something.h'.
We fixed this problem in a later release by further massaging the
output of 'gcc' to include a dummy dependency for each header file.
Info Catalog
automake-history: First Take on Dependencies
automake-history: Dependency Tracking Evolution
automake-history: Dependencies for the User