Next: Dependencies for the User, Previous: First Take on Dependencies, Up: Dependency Tracking Evolution
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).
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.