ddunbar added a comment.
In https://reviews.llvm.org/D30882#1074822, @dexonsmith wrote:
> I don't think this is quite right. I know at least `make`-based incremental
> builds wouldn't deal well with this.
This is actually not a novel problem w.r.t. this patch. The exact same
situation comes up with Makefile-included .d files and when one of the
referenced headers is removed.
This is typically solved somewhere in the build system, for example Make has
`-include`, and Ninja and llbuild have explicit support for this situation.
I agree we might want to tread cautiously on how we change the .d output, but
in this case I think it might be safe.
If we decide this isn't safe, then we may want to consider a new flag which
tracks *all* anti-dependencies (file's for which Clang checked existence but
did not exist), and include that here. The major concern with that approach is
it is a much larger list, and while it would support being substantially more
correct, it is also well beyond what people currently expect out of the build
system + compiler generated deps approaches.
> Given t.cpp:
>
> #if __has_include("missing.h")
> #endif
>
>
> t.d will be:
>
> t.o: missing.h
>
>
> Since the build system doesn't know how to generate missing.h, when t.cpp
> changes the build system will stop dead in its tracks.
>
> Knowing the list of files that are //potential// inputs to `t.o` seems
> useful, but we should probably do that under a separate flag. And if it's a
> separate flag, we might consider giving it a better name than `-MF`...
https://reviews.llvm.org/D30882
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
