Hacker News Reader

Comment by leni536 | Hacker News Reader

Is this always correct? The %.d files don't depend explicitly on the %.c files so they aren't rebuilt every time at the beginning of the make run, so old dependencies are included after a change in header dependencies. I'm still trying to construct an example where such a makefile breaks though.

View on HN

The only case it becomes problematic is if you delete a header file, as make won't know how to remake it and won't recompile the C file (removing the dependency) until it has done so. There are two options to resolve this:

Also specify -MP on the GCC command line, which causes GCC to emit an empty rule for all the header files, like this:

    foo.o: foo.c foo.h bar.h
    foo.h:
    bar.h:

Alternatively, you can write a generic empty header creation rule:

    %.h:

Which has the same effect.

Neither make nor any of its alternatives or improvements get header files completely right. This is because compilers simply do not emit all of the information. A build tool not only has to know about the header files found, to monitor them for changes, but also has to know about the places where header files were not found, to monitor for files suddenly appearing there. I wrote a C++ preprocessor that would spit out both sets of information, for use with redo, but I've never published it. Without this information things can end up not being re-built correctly in a number of cases that one can encounter in practice.

> A build tool not only has to know about the header files found, to monitor them for changes, but also has to know about the places where header files were not found, to monitor for files suddenly appearing there.

I wonder how my makefile fails here.

Reply on news.ycombinator.com