6 ms·

I just tested this and I think you are incorrect. Bazel will appear as if it's rebuilding all of them (it lists a dozen files), but it's really just checking th

I just tested this and I think you are incorrect. Bazel will appear as if it's rebuilding all of them (it lists a dozen files), but it's really just checking the caches for them. Try running `bazel build -s` and watch what commands it actually runs. Note that adding and removing files (including through a glob) does always cause a rebuild though (because it's a change of the rule). This is a deficiency of bazel.

joshuamorton 7y ago
You can skip that if you use libraries, it won't even check the cache or need to relink. That's faster, much faster at scale. The other nice thing is you get dead code elimination for free.
- SolarNet 7y ago
  Sure, but my point was that Bazel is doing file/include analysis so medium sized multi-header libraries are not penalized.
  - joshuamorton 7y ago
    That's not correct, or at least it's not always correct. C may have some special support, but other languages don't. The other place this is obvious is with tests. If you have a unit test per source, a change to any source will return all tests, splitting reduces this.
    - SolarNet 7y ago
      Then that is a problem with those language's implementations. Bazel allows for it, it is on those language implementations to provide support. Notably I am not aware of many languages that easily allow access to their dependency graphs (especially without third party tools anyway). To me this seems more of an issue with the languages in question than with Bazel.
      - joshuamorton 7y ago
        But again, bazel doesn't want you to do that. The more information bazel has, the more it can do for you. If you stick to 1-lib-per-source-file, dead code elimination, across your entire codebase, however large it is, can be done by a single reverse dependency query across every language, even those that don't have compilers. In other words, correctly using bazel gives you access to all the cool magic linkers do without having to do the work to implement it. And it adds value even for the ones that do (like C++, again: you'll run fewer tests).
        SolarNet 7y ago
        I mean sure, I'm not necessarily disagreeing that many people could do with fewer source files per library. But I also think you are pathologically misusing the tool along the lines of creating an NPM library for the left-pad function. Bazel has other tools for mitigating excessive test running (like test size/time descriptions and parallel test running) running too many tests has never been a problem I have encountered with even my dozen source file bazel libraries. Bazel also has smart test runners that can split up the tests in a test binary and run it in parallel, and I don't have to write a dozen lines for every C++ library.
        joshuamorton 7y ago
        > I mean sure, I'm not necessarily disagreeing that many people could do with fewer source files per library. But I also think you are pathologically misusing the tool along the lines of creating an NPM library for the left-pad function. I'm literally quoting Google's best practices for using bazel/blaze. > Bazel has other tools for mitigating excessive test running (like test size/time descriptions and parallel test running) running too many tests has never been a problem I have encountered with even my dozen source file bazel libraries. Bazel also has smart test runners that can split up the tests in a test binary and run it in parallel, and I don't have to write a dozen lines for every C++ library. Right, but here's the key thing: You're still running the test. My way, you just don't, and you lose nothing. You use less CPU, and less time.

joshuamorton 7y ago

You can skip that if you use libraries, it won't even check the cache or need to relink. That's faster, much faster at scale. The other nice thing is you get dead code elimination for free.

SolarNet 7y ago
Sure, but my point was that Bazel is doing file/include analysis so medium sized multi-header libraries are not penalized.
- joshuamorton 7y ago
  That's not correct, or at least it's not always correct. C may have some special support, but other languages don't. The other place this is obvious is with tests. If you have a unit test per source, a change to any source will return all tests, splitting reduces this.
  - SolarNet 7y ago
    Then that is a problem with those language's implementations. Bazel allows for it, it is on those language implementations to provide support. Notably I am not aware of many languages that easily allow access to their dependency graphs (especially without third party tools anyway). To me this seems more of an issue with the languages in question than with Bazel.
    - joshuamorton 7y ago
      But again, bazel doesn't want you to do that. The more information bazel has, the more it can do for you. If you stick to 1-lib-per-source-file, dead code elimination, across your entire codebase, however large it is, can be done by a single reverse dependency query across every language, even those that don't have compilers. In other words, correctly using bazel gives you access to all the cool magic linkers do without having to do the work to implement it. And it adds value even for the ones that do (like C++, again: you'll run fewer tests).
      - SolarNet 7y ago
        I mean sure, I'm not necessarily disagreeing that many people could do with fewer source files per library. But I also think you are pathologically misusing the tool along the lines of creating an NPM library for the left-pad function. Bazel has other tools for mitigating excessive test running (like test size/time descriptions and parallel test running) running too many tests has never been a problem I have encountered with even my dozen source file bazel libraries. Bazel also has smart test runners that can split up the tests in a test binary and run it in parallel, and I don't have to write a dozen lines for every C++ library.
        joshuamorton 7y ago
        > I mean sure, I'm not necessarily disagreeing that many people could do with fewer source files per library. But I also think you are pathologically misusing the tool along the lines of creating an NPM library for the left-pad function. I'm literally quoting Google's best practices for using bazel/blaze. > Bazel has other tools for mitigating excessive test running (like test size/time descriptions and parallel test running) running too many tests has never been a problem I have encountered with even my dozen source file bazel libraries. Bazel also has smart test runners that can split up the tests in a test binary and run it in parallel, and I don't have to write a dozen lines for every C++ library. Right, but here's the key thing: You're still running the test. My way, you just don't, and you lose nothing. You use less CPU, and less time.