Automatic Dependency Generation

Question

I was reading through Automatic Dependency Generation in the make manual and I can't figure out why this functionality is needed. The project that I am working on and I started writing from scratch is structured like this:

• each unit (library) has it's own folder
• each .cpp file should include a single .h file with the same name from the same directory. OK, this rule can be a bit too restrictive, like in the case of circular dependencies, in which case I may include another .h file, just as described in the next rule
• when including other headers in a .h file, always use paths relative to the root directory of the project, if the dependency is located in another unit (library). Otherwise, just include the name of the file.

In the makefile, I pass -I . to the compiler. When it encounters a .cpp file in directory X, it will search for the .h file in the same directory (or in the . directory). When parsing the .h file, it will encounter includes relative to the . folder, so it will know where to look for them.

Now, why would anybody want to generate a list of dependencies with the -M flag and mess with sed to produce an obscure .d file (dependencies fie) if code can be structured like I described above? I don't see the point of generating the specific list of dependencies from a code file.

Answer 1

That's just how makepp works. Dependencies are detected automatically. In your case you won't even need a makefile (if you don't mind specifying the target in the command).

The built in linker rule has the goody of automatically deducing object files. If you say makepp proggie, it will scan proggie.c (or .cpp or whatever you have) for include statements. For each statement it will look if there is a matching .o file that can be built, and if so scan that recursively. All the .o files discovered this way are then built and linked together.

Or your makefile could be a one liner to avoid specifying the target every time:

$(phony all): proggie

Answer 2

Because in practice, each source file will depend on multiple header files. If you don't recompile the source file each time any of those headers changes, there is a good chance you will end up with an inconsistent binary.