4 ms·
That case is the easy case (though caching of included files is problematic in most build systems due to inability to express dependency on the inexistence of t
by Peaker 12y ago
That case is the easy case (though caching of included files is problematic in most build systems due to inability to express dependency on the inexistence of the included name in a previous include directory).
The hard case is changing defined macros in a way that doesn't matter but does pass extra -D flags to the compilation units. You can detect this by ad hoc preprocessor aware logic, or you can have a separate build step for preprocessing and do content aware rebuilds that avoid rebuilding if the preprocessed text is identical.
- taeric 12y agoRight, I was just saying that some of the build environments are "smarter" than you might give credit. I think you'd be surprised how many people don't know about gcc -M and friends.
- Peaker 12y agoOne thing almost nobody knows about gcc -M is that it is wrong :( And for 2 different reasons: 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.
- taeric 12y agoA) 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?
- Peaker 12y agoA) 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.
- taeric 12y agoAh, 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?
- Peaker 12y agoI'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.
- taeric 12y agoOh, 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.