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.
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.