I'm not talking about autotools :) I've always avoided autoconf/et-al. I'm talking about make-based builds not being able to use gcc -M properly, because it doesn't work when header files need to be generated due to their #include directive.

-M could in theory output the inexistence stuff, but then most build systems couldn't even express that dependency.

Oh, I think I see what you mean. -M will catch when a C file needs to be changed due to any header in the #include path, but not necessarily the header files.

For that, I would assume you would still have to do that by hand for the header. There may be some autotools thing that covers it. Though.... even then, I'm not sure what the point is. If the header file itself is generated, then you already have the dependency on what it generates from.

The only scenario I think I see as not covered is when there is an include in an #if that flips from not taken to taken. Though, that does seem fairly edge case.

I think I really just need to see an example of the inexistance stuff. In particular, one that is expected to change between non-clean builds.

There are two independent problems here.

Problem A:

foo.c: #include "bar_auto.h"

when you have a rule "%_auto.h: %_auto.xml".

gcc -M on foo.c will not tell you about the dependence on "bar_auto.h", but will rather fail. With buildsome or a better #include scanner, you will know that foo.o depends on bar_auto.h, even though bar_auto.h does not yet exist.

Problem B:

x.c: #include "bla.h"

a/bla.h does not exist

b/bla.h does exist

gcc -Ia -Ib -o x.o -c x.c

gcc -M tells us that x.o depends on b/bla.h. We cache this information to avoid rerunning gcc -M every time. Then someone adds a/bla.h. A rebuild will change x.o, but "make" or whatever build system cached the result of "gcc -M" will not rebuild anything.

You might say "gcc -M" should be rerun each time, but this is extremely wasteful, as there's no reason to rescan all the .c/.h files every time, when they did not change.