On Fri, May 12, 2023 at 01:13:04 -0700, 'Ingo Müller' via ninja-build wrote:
> Similar to Stefano, I don't see any occurrence of tbb.h anywhere in my
> project (LLVM) or the ninja.build file. Also, if I look at the depfile
> (produced with `ninja -d keepdefile`), that file is not among the
> dependencies. However, if I grep for `tbb.h` in all of the header files, I
> do get the following output:
>
> /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/x86_64-linux-gnu/c++/12/bits/c++config.h:829:#
> define _GLIBCXX_USE_TBB_PAR_BACKEND __has_include(<tbb/tbb.h>
This is a stdlib header, so it's no wonder that it doesn't appear in
your projects.
> If I remove that line the message above about a phony edge goes away. This
> suggest that something is parsing my header files wrongly and detects and
> edge where there shouldn't be one...
So it seems that GCC is reporting `__has_include` queries in `-MF`
outputs. I'm not 100% sure that this is correct (as it doesn't care if
the file *changes*, but *exists* and, as you found out, existence
queries are not well-defined/handled in such situations). This is
probably worth an issue to GCC (and I'd also coordinate Clang with its
behavior in this area; MSVC should also be checked for its behavior
here just for completeness).
Note that not reporting this would mean that caches and such are
"desynced" with the system state of TBB if built when it is not present
and then rebuilt afterwards (i.e., the cache won't notice the
installation and will gladly provide the no-TBB state even though TBB is
now present). The reverse is probably fine in practice as any truth from
that query is likely to follow immediately with an `#include` of the
queried header.
--Ben