By “mirroring the includes” do you just mean listing the .h files in the build files? Don’t most build systems already have that problem for cpp files? Tbh I prefer also being explicit about the headers packaged in a library as well as the source.
So far, it seems to result in a more accurate Makefile (with includes), but my project is pretty small. The Erlang compiler can also output a dependency file, with pretty similar looking arguments, so that helps too.
> By “mirroring the includes” do you just mean listing the .h files in the build files?
It's not just listing them once, so they get installed or such. You need to list them as dependencies for objects that get built.
> I just found this tutorial to get the compiler to list your dependencies for you with (GNU) Make
Yea, that works very well. A lot of projects sticking with make use that via some makefile hackery (e.g. postgres). Cmake etc do so automatically as well(at least for the common generators).
But with bazel you have to basically maintain that manually on a granular basis. So if you add a new #include to some random .c file you often also need to add that as a dependency. There's a bunch of error checking around that to make it easier to get it right, but it's still seems like a lot of work to me.
