9 ms·

Sure I'll just go ahead and stick my fly weight class and it's provider class in two different libraries. And have one of them expose their shared internal head

Sure I'll just go ahead and stick my fly weight class and it's provider class in two different libraries. And have one of them expose their shared internal header that is not meant for public usage. That's not going to cause any issues at all (sarcasm). One source file per library and one source file per object is an example of two policies that will conflict here (and I'm not trading code organization for build organization when I can just as easily use the features intended for this situation). Meanwhile in the real world limiting the accessibility of header files not meant for public use prevents people from depending on things they shouldn't. Organizing libraries on abstraction boundaries regardless of code organization allows for more flexible organization of code (e.g. for readability and documentation). And so on. This is why these feature exists and why Google projects like both Tensorflow and Skia don't follow the practices you are espousing here pathologically. > But to be frank, there are parts of my job that I literally would be unable to accomplish if my coworkers did what you suggest. Then you are incompetent and bad at your job. To be blunt I would recommend firing an engineer who pathologically misused a build tool in ways that encourage hard to read code and difficult to document code, while also making the build bloated and more complicated, all in the name of barely existent (and not at all relevant) performance improvements. And then said they couldn't do their job unless everyone conformed to that myopic build pattern. It's like what, an extra 4 characters to get the list of code files in a library from a bazel query? What in the world could you possibly be doing that having to iterate over five files rather than one makes your job impossible.

joshuamorton 7y ago
Bazel supports visibility declarations your private internal provider can be marked package, or even library-private. > Tensorflow Tensorflow is a perenial special case at Google. It's a great tool, but it's consistent disregard for internal development practices is costly. A cost I've had to pay personally before. > Then you are incompetent and bad at your job No, I just don't have the time or interest in reimplement language analysis tools when I don't need to.
- SolarNet 7y ago
  > No, I just don't have the time or interest in reimplement language analysis tools when I don't need to. And I don't have the time or interest to do it by hand when bazel already has that.
  - joshuamorton 7y ago
    But it doesn't actually have that. It has that for 1 very specific usecase, sometimes. Its very much not generic or intentionally built into bazel, and I am almost certain that there are more complex cases where that caching will break down (for example when the various deps import each other, or as mentioned: tests). Especially when its easier to have tooling automatically manage build files for you, so you don't even have to do it by hand!
    - SolarNet 7y ago
      > But it doesn't actually have that. It has that for 1 very specific usecase, sometimes. I mean not really, it's there enough that for all practical cases it exists effectively. I would be extremely surprised if that wasn't intentional when any other C++ build tool makes use of it extensively. I would have laughed bazel out of the room if it didn't make use of the fact that nearly all C++ compilers provide nicely formatted lists of the files a given file depends on. Also it does work for tests perfectly fine. > Especially when its easier to have tooling automatically manage build files for you, so you don't even have to do it by hand! And this managing build file tooling is public? Because I am not at all aware of any automatic tools for bazel along those lines. Which really is my frustration with bazel's google developers, their views are eternally myopic about how other people use their tools (e.g. using C++17 properly means re-writing the whole toolchain from scratch, have fun!). Yet those views are based on a closed and mostly unpublished ecosystem. Let alone how terrible bazel does with dynamic libraries on windows (each cc_library then outputs a dll! yay!). I don't think you realize how for anyone outside of Google bazel's tagline might as well be "The best terrible option".
      - joshuamorton 7y ago

joshuamorton 7y ago

Bazel supports visibility declarations your private internal provider can be marked package, or even library-private. > Tensorflow Tensorflow is a perenial special case at Google. It's a great tool, but it's consistent disregard for internal development practices is costly. A cost I've had to pay personally before. > Then you are incompetent and bad at your job No, I just don't have the time or interest in reimplement language analysis tools when I don't need to.

SolarNet 7y ago
> No, I just don't have the time or interest in reimplement language analysis tools when I don't need to. And I don't have the time or interest to do it by hand when bazel already has that.
- joshuamorton 7y ago
  But it doesn't actually have that. It has that for 1 very specific usecase, sometimes. Its very much not generic or intentionally built into bazel, and I am almost certain that there are more complex cases where that caching will break down (for example when the various deps import each other, or as mentioned: tests). Especially when its easier to have tooling automatically manage build files for you, so you don't even have to do it by hand!
  - SolarNet 7y ago
    > But it doesn't actually have that. It has that for 1 very specific usecase, sometimes. I mean not really, it's there enough that for all practical cases it exists effectively. I would be extremely surprised if that wasn't intentional when any other C++ build tool makes use of it extensively. I would have laughed bazel out of the room if it didn't make use of the fact that nearly all C++ compilers provide nicely formatted lists of the files a given file depends on. Also it does work for tests perfectly fine. > Especially when its easier to have tooling automatically manage build files for you, so you don't even have to do it by hand! And this managing build file tooling is public? Because I am not at all aware of any automatic tools for bazel along those lines. Which really is my frustration with bazel's google developers, their views are eternally myopic about how other people use their tools (e.g. using C++17 properly means re-writing the whole toolchain from scratch, have fun!). Yet those views are based on a closed and mostly unpublished ecosystem. Let alone how terrible bazel does with dynamic libraries on windows (each cc_library then outputs a dll! yay!). I don't think you realize how for anyone outside of Google bazel's tagline might as well be "The best terrible option".
    - joshuamorton 7y ago