4 ms·

I have never seriously used bazel. Just looking at it, I found the the thought of manually mirroring all #includes to the build configuration in a big project p

I have never seriously used bazel. Just looking at it, I found the the thought of manually mirroring all #includes to the build configuration in a big project pretty aggravating. Is that not really an issue in practice? Do people automate that away?

mehrdadn 6y ago
People use globs (wildcards) and group targets together to make it more manageable. It still does present some friction moving forward, but it's much more pleasant than listing every file individually, and there's a kind of an elegance to the system when you get used to it. And it does warn you if you include files that you didn't depend on. (Pro tip: never use include=...; always depend directly on a cc_library(hdrs=...).) That, said I do wish there was a way to make it easier and avoid the redundancy.
bertr4nd 6y ago
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.
- toast0 6y ago
  I just found this tutorial to get the compiler to list your dependencies for you with (GNU) Make http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ http://make.mad-scientist.net/papers/advanced-auto-dependenc... 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.
  - anarazel 6y ago
    > 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.
jsolson 6y ago
Google automates it away, to the extent that if you run our "rebuild if anything changes" tool it will automatically run the BUILD cleaning tool if any layering violations happen or if any dependencies are absent.

mehrdadn 6y ago

People use globs (wildcards) and group targets together to make it more manageable. It still does present some friction moving forward, but it's much more pleasant than listing every file individually, and there's a kind of an elegance to the system when you get used to it. And it does warn you if you include files that you didn't depend on. (Pro tip: never use include=...; always depend directly on a cc_library(hdrs=...).) That, said I do wish there was a way to make it easier and avoid the redundancy.

bertr4nd 6y ago

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.

toast0 6y ago
I just found this tutorial to get the compiler to list your dependencies for you with (GNU) Make http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ http://make.mad-scientist.net/papers/advanced-auto-dependenc... 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.
- anarazel 6y ago
  > 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.

jsolson 6y ago

Google automates it away, to the extent that if you run our "rebuild if anything changes" tool it will automatically run the BUILD cleaning tool if any layering violations happen or if any dependencies are absent.