Also, any "make" program for C should automatically detect dependencies between files because this information is present in the code and it doesn't make sense to duplicate it.
$ cat Makefile
CFLAGS := -MD -MP
hello: hello.o x.o y.o
-include *.d
$ echo '#include "x.h"' > x.c
$ echo '#include "y.h"' > y.c
$ touch x.h y.h
$ echo 'int main(void) {}' > hello.c
$ make
cc -MD -MP -c -o hello.o hello.c
cc -MD -MP -c -o x.o x.c
cc -MD -MP -c -o y.o y.c
cc hello.o x.o y.o -o hello
$ touch x.h
$ make
cc -MD -MP -c -o x.o x.c
cc hello.o x.o y.o -o hello* http://jdebp.uk./FGA/introduction-to-redo.html#CompilerDefic...
https://www.gnu.org/software/make/manual/html_node/Remaking-...
https://stackoverflow.com/questions/2131213/can-you-make-val...
This requires that either you implement or shell out to a C/C++ parser as part of the dependency resolution step (which has to happen prior to the actual compilation). This will slow down your compilation a lot unless you're able to parse C/C++ as fast as your make/bazel/whatever language.
Unfortunately, current C and C++ compilers do not emit all of the information that they possess internally, only less than half of it (the positive information about files found, not the larger amount of negative information about non-existent files that were searched and would change the build if they were to exist).
You have a.cc that depends on b.cc, but some tool generates b.cc, so it may not exist (but `b.do` does). If I invoke `a.do` to compile `a.cc`, and don't directly declare b.cc as a dependency in the .do file, the theoretical compiler will resolve that it depends on b.cc, and note that that doesn't exist, and then what?
In the bazel world, since you define the dependency graph explicitly before invoking any compiler, you can't run into this issue, but in situations where you need to get dep info from the compiler...what happens with stuff like this?