Hacker News Reader

Comment by leni536 | Hacker News Reader

One really neat thing about make: If you include other makefiles then before including them make checks if there are prerequisites of these files and rebuilds them as needed. One can use this to automatically generate header dependencies of translation units for C/C++ projects. Some of the relevant lines in one of my Makefiles:

     include ${DEPENDS}
     
     ${DEPDIR}/%.d: ${SRCDIR}/%.${SRCEXT}
     	@mkdir -p ${shell dirname $@} ; \
     	$(CC) -MM ${INCLUDE} -mmcu='${AVRTARGET}' $< >> $@

If any file in the "include" line needs updating then it is generated by gcc and included in the same make run. I didn't find a good documentation about this feature and I discovered this with make's pretty verbose -d option. Previously I did something like this using multiple makefiles and recursively calling make which is generally frowned upon (for valid reasons).

View on HN

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)

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.

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