3 ms·

I think these days you're better off using -MMD to generate header dependencies at the same time as compiling, rather than doing it in a separate rule. %.o

by efaref 10y ago

I think these days you're better off using -MMD to generate header dependencies at the same time as compiling, rather than doing it in a separate rule. %.o: %.c $(CC) $(CFLAGS) -MMD -c $< -include $(OBJECTS:.o=.d)

leni536 10y ago
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.
- efaref 10y ago
  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.
  - JdeBP 10y ago
    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.
    - leni536 10y ago
      > 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.

by efaref 10y ago

leni536 10y ago

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.

efaref 10y ago
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.
- JdeBP 10y ago
  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.
  - leni536 10y ago
    > 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.