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.