A) doesn't make sense. If the header is autogenerated, then it has a dependency specified elsewhere. So, I'm not sure how that is a failure of -M. (That is, it will tell you that this file depends on a header. It is up to other rules to say that header is autogenerated. Right?)
B) This makes sense, though I don't necessarily see how that could happen. It won't help you not rerun the -M hit, but the flow is: "rerun -M" on files to get list of dependencies, restart with those dependency list loaded and see what needs to be rebuilt. Right?
A) Usually, there's a rule like: auto_%.h from %.xml Then you want #include "auto_foo.h" to be found, and cause auto_foo.h to be auto-generated from foo.xml, without explicitly mentioning "foo.xml" anywhere in the build system itself.
B) If you rerun -M every time you try to build, your empty builds are going to be quite expensive. It makes sense to cache that, and only rescan files when they or their #included files changed. But then you need to be able to do the file-inexistence dependency thing or it's wrong.
Ah, I'm really just getting used to the autotools conventions, where I don't think any wildcard rules are used. (And, even then, I'm still just a learner.)
I see what you are saying with B, but I don't have quite enough experience to know exactly how expensive that is. I also don't know enough about the kernel build to know what it is doing.
Also, I'm curious why the -M flag can't output the inexistance stuff. I guess it would be purely heuristic?
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.
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.
A) If the headers are supposed to be auto-generated, it will uninformatively fail
B) If everything is successful, it will not tell you about all the paths it depends on not existing.
gcc -M -Ia -Ib foo.c
Will tell you about b/x.h being a dependency, but will not tell you about a/x.h not-existing being a dependency.