4 ms·

Bazel probably wasn't a good fit for that project, especially if your makefile was simple. But where it does work well, is when you have a large complex codeba

by thayne 4y ago

Bazel probably wasn't a good fit for that project, especially if your makefile was simple. But where it does work well, is when you have a large complex codebase in a monorepo, and you need reliable caching to keep build times down.

thechao 4y ago
C + Makefile + CCache: I just `find . -name "*.h"` and throw that as the dependency of every C file, and then let ccache/make figure out the rest. My code base runs upwards of 10+ million LOC, and incremental builds are in the "hundreds of milliseconds" and "clean" builds (ccache clean, mind you) are about 30s. Truly clean builds (on a scratch system) are ~2 minutes. We do spend time making sure our very long files still compile very quickly -- we're careful to stay away from code that exercises pathological paths through the compiler. I've found that a good laptop can compile ~20kloc/(s-thread) throughput with parallel builds (it varies from 1000–100000loc/(s-thread)).
- thayne 4y ago
  That's specific to c. Bazel is often used in cases where you have multiple languages in use, and possibly dependencies between projects using different languages. > I just `find . -name "*.h"` That sounds like it would cause problems with not triggering a build if a .h file is deleted. And would trigger unnecessary builds if any .h file is modified. But if your builds are that fast, maybe that isn't a problem.
  - thechao 4y ago
    It is specific to C/C++, for sure -- I started with that. ccache is going to be as fast as any checksum dependency tracker --- otherwise you're relying on a timestamp, which isn't any better than "bare" Make. We use `*.d` rules from the `-MD` flag to prevent the "deleted header" case. Considering the brevity of the Makefile (it looks like a "basic" build), performance, and the practical robustness, it's in a pretty great trade-off space.
    - thayne 4y ago
      From what you've described I definitely don't think it would be worth migrating what you have to bazel. My point is just that there are environments where it does provide benefits.
nsteel 4y ago
At the risk of looking dumb here, don't incremental builds take care of this, how is caching different? ? Make gives me incremental builds and my makefile lets me define the inputs and the outputs. What am I missing with Bazel?!
- jvolkman 4y ago
  1. Make uses mtime to determine whether inputs have changed. Bazel uses a hash of all inputs to the target (file contents + other inputs like environment variables) 2. Make lets you define inputs and outputs, but doesn't enforce them. Bazel sandboxes build actions; if you try to import a dependency that you haven't listed as a direct or transitive dependency, the build will fail. This is leads to users never (or at least very rarely) having to run `bazel clean`.

by thayne 4y ago

thechao 4y ago

C + Makefile + CCache: I just `find . -name "*.h"` and throw that as the dependency of every C file, and then let ccache/make figure out the rest. My code base runs upwards of 10+ million LOC, and incremental builds are in the "hundreds of milliseconds" and "clean" builds (ccache clean, mind you) are about 30s. Truly clean builds (on a scratch system) are ~2 minutes. We do spend time making sure our very long files still compile very quickly -- we're careful to stay away from code that exercises pathological paths through the compiler. I've found that a good laptop can compile ~20kloc/(s-thread) throughput with parallel builds (it varies from 1000–100000loc/(s-thread)).

thayne 4y ago
That's specific to c. Bazel is often used in cases where you have multiple languages in use, and possibly dependencies between projects using different languages. > I just `find . -name "*.h"` That sounds like it would cause problems with not triggering a build if a .h file is deleted. And would trigger unnecessary builds if any .h file is modified. But if your builds are that fast, maybe that isn't a problem.
- thechao 4y ago
  It is specific to C/C++, for sure -- I started with that. ccache is going to be as fast as any checksum dependency tracker --- otherwise you're relying on a timestamp, which isn't any better than "bare" Make. We use `*.d` rules from the `-MD` flag to prevent the "deleted header" case. Considering the brevity of the Makefile (it looks like a "basic" build), performance, and the practical robustness, it's in a pretty great trade-off space.
  - thayne 4y ago
    From what you've described I definitely don't think it would be worth migrating what you have to bazel. My point is just that there are environments where it does provide benefits.

nsteel 4y ago

At the risk of looking dumb here, don't incremental builds take care of this, how is caching different? ? Make gives me incremental builds and my makefile lets me define the inputs and the outputs. What am I missing with Bazel?!

jvolkman 4y ago
1. Make uses mtime to determine whether inputs have changed. Bazel uses a hash of all inputs to the target (file contents + other inputs like environment variables) 2. Make lets you define inputs and outputs, but doesn't enforce them. Bazel sandboxes build actions; if you try to import a dependency that you haven't listed as a direct or transitive dependency, the build will fail. This is leads to users never (or at least very rarely) having to run `bazel clean`.