61–70 of 204 posts
What does Bazel do exactly?
Earlier quoted context omitted.
Visual Studio (used to?) come with nmake, a mostly compatible version of Make.
used to come with mostly compatible version of . Yup.
Problem: There are N confusing build systems with arcane rules and you just want to compile your program. Solution: Design a simple, straightforward build tool. Problem: There are N+1 confusing build systems with arcane rules.
Bazel is almost a standard for build systems at this point. Did you ever use it, or at least see what a bazel build rule looks like [1] before calling it arcane? [1] https://docs.bazel.build/versions/1.0.0/tutorial/cpp.html#un...
I only wish Bazel had been written in a language that produced native binaries like C++ or Go instead of Java. It seems like a waste for me as a non-Java developer to install Java on my dev machine just for Bazel.
I hope the release of 1.0 is an indication that Bazel is taking interface stability more seriously.
Earlier quoted context omitted.
My experience with using the Google-internal version of Bazel is that yes, you want to give up all other tools to use this. Having a proper dependency graph makes it possible to cache maximally and accurately, and that results in fast builds. You don't need it if you only have like one go program that you're building, but you will start to see the disadvantages when you have a handful of things you build. Did you bui…
Dude, IDK if you have used bazel OUTSIDE of Google, but I've used it both inside and outside of Google and I can tell with 99.999% confidence that the experiences are dramatically different. Bazel != Blaze (internal version of Bazel). 1. Google has a well maintained monorepo. Most companies don't. That diminishes the meaning of a good build system in the very first place; even if Bazel is powerful, with separate repo…
Is it worth giving up language-specific build tools (CMake, Maven, Gradle and others) for one build tool to rule them all?
My experience with using the Google-internal version of Bazel is that yes, you want to give up all other tools to use this. Having a proper dependency graph makes it possible to cache maximally and accurately, and that results in fast builds. You don't need it if you only have like one go program that you're building, but you will start to see the disadvantages when you have a handful of things you build. Did you bui…
Pretty much every other build system (e.g., make) is rooted in having a proper dependency graph. This is not a unique property of Bazel.
The lack of backwards compatibility between Bazel versions has been the deal-killer for me thus far. Old build instructions should work with newer releases of the same tools. It's important for the tools to remain compatible because you can't change the instructions contained in old releases. I hope the release of 1.0 is an indication that Bazel is taking interface stability more seriously.
I have to say, having used a number of Google's tools over the years: basel, coral sdk, maps api and perhaps others, I'm always surprised at how 'how ya doing' the experience is. Don't get me wrong, I appreciate their tools and its openness, but I wish Google spend a bit more time doing software engineering, and less throwing shit against a wall ascertaining stickiness.
The lack of backwards compatibility between Bazel versions has been the deal-killer for me thus far. Old build instructions should work with newer releases of the same tools. It's important for the tools to remain compatible because you can't change the instructions contained in old releases. I hope the release of 1.0 is an indication that Bazel is taking interface stability more seriously.
Earlier quoted context omitted.
My experience with using the Google-internal version of Bazel is that yes, you want to give up all other tools to use this. Having a proper dependency graph makes it possible to cache maximally and accurately, and that results in fast builds. You don't need it if you only have like one go program that you're building, but you will start to see the disadvantages when you have a handful of things you build. Did you bui…
> Having a proper dependency graph makes it possible to cache maximally and accurately, and that results in fast builds. Pretty much every other build system (e.g., make) is rooted in having a proper dependency graph. This is not a unique property of Bazel.
[1] https://www.microsoft.com/en-us/research/uploads/prod/2018/0...