I don't see how build2 can be in the same spirit as Bazel when it misses the main advantage of Bazel
I never said build2 is "in the same spirit" as Bazel (whatever that means). I said it fixes the same problems as OP listed.
> I said it fixes the same problems as OP listed.
The OP listed noted that hermeticity is required for fast builds, and that humans can't be relied upon to provide hermeticity as a property. How does build2 guarantee hermeticity or otherwise support fast builds without a clean room solution a la bazel?
Bazel has good support for both languages. My personal experience is with the JavaScript + Rollup (or TypeScript + Rollup) rules for Bazel. There are rules for Bazel + Yarn integration and although I use them, I’m not really qualified to give an opinion. With the TypeScript projects I work on, you have an ordinary yarn.lock and some extra Bazel rules in WORKSPACE to install the packages, and then you use some Bazel r…
What helped you push through the steep learning curve when you started? Asking cause I was excited recently to try Bazel specifically for a Typescript monorepo, and the learning curve crushed me.
I started by going through the Java tutorial[1] to get a feel for it. It's fairly approachable and you don't actually need any Java knowledge.
Once you familiarize yourself with the concept of rules and targets, you can follow the instructions for whichever ruleset you want to use. The official one for JS is rules_nodejs[2]
Another thing that really helped me cement my understanding of Bazel was to deep dive into Starlark and write my own rules. The examples repo[3] is a great resource for that
Am I correct in thinking that Bazel is a fantastic fit for golang with modules?
In theory, yes. In practice... you will need to either a) force everyone in your team to never use native Go tools ever, or b) cobble together third-party tools to bridge the two worlds. Start with https://github.com/bazelbuild/bazel-gazelle and see how deep the rabbit hole goes.
It's possible, but it's not trivial, and not nearly as smooth as using the Go tools in the first place. Unless you have a hair-on-fire problem dealing with cross-language dependencies or insanely long build times, it will probably not be a good use of your time.
Bazel may be 1.0 and the internal abstractions of dag solving etc are rock solid from years of use inside Google, but the ecosystem around Bazel is quite bad at the moment. They've been breaking backwards compatibility constantly, so rules authors have struggled to keep up (hopefully done now that it's 1.0). The reason the ecosystem maturity is so important for bazel is because its design encourages complete reimplem…
About the container stuff specifically, I think the different solution provided here versus off-the-shelf Docker is not merely to be compatible with Bazel. Rather it looks like, from having used it modestly, an intentionally different way of thinking about container builds, aiming toward different performance characteristics that scale etc. I can't think of any reason you couldn't call the docker tools in a genrule()…
Docker's build system is really strange. The build cache assumes that your dependency tree is linear, and it will invalidate the build cache if any file dependency changes, but a `RUN apt install foo` doesn't invalidate the cache--it's just assumed that every RUN statement is idempotent. Further, the Dockerfile's COPY is close to worthless--if you want to import all of your repo's Python packages, you have to put them all under a single directory or you have to copy them one by one (or you copy the whole repo and deal with the fact that every JS and README change will trigger a complete rebuild). Also, everything depends on a running Docker daemon and last I checked, the performance degraded if you tried to build multiple images in parallel.
About the container stuff specifically, I think the different solution provided here versus off-the-shelf Docker is not merely to be compatible with Bazel. Rather it looks like, from having used it modestly, an intentionally different way of thinking about container builds, aiming toward different performance characteristics that scale etc. I can't think of any reason you couldn't call the docker tools in a genrule()…
Yeah, I actually like the speed with which it can build images. But it's a risk that it's an entirely different implementation. If you have a team of people to deal with maintenance, then it's worth it. If you don't, then when an incompatibility crops up, you're stuck until you can hack around it. Having a really well maintained docker ruleset is crucial if you don't have that team
OCI provides a standard container image format, at least. Assuming your whole toolchain is compatible, then it shouldn't be an issue.
I never said build2 is "in the same spirit" as Bazel (whatever that means). I said it fixes the same problems as OP listed.
> I said it fixes the same problems as OP listed. The OP listed noted that hermeticity is required for fast builds, and that humans can't be relied upon to provide hermeticity as a property. How does build2 guarantee hermeticity or otherwise support fast builds without a clean room solution a la bazel?
The OP was vague on why exactly hermetic builds are required to achieve fast builds. The only concrete thing they mentioned is caching which doesn't require hermetic builds (in the strict sense, as in preventing any outside changes) provided you can detect changes accurately.
To give a specific example, Bazel may prevent you from accidentally using a different version of the compiler while build2 will detect that you are attempting to use a different version.
I hope that this 1.0 status will prompt the Qt people to take a closer look at Bazel, but that's probably strongly conditioned on the quality of Windows support. Qt Co. have indicated that CMake is the most likely replacement for qmake in Qt 6, which would be a lateral change at best. Is anyone using Bazel to ship cross-platform GUI applications?
Isn’t Bazel jre based? I don’t think that something like Qt will ever go for a build tool that requires the whole java runtime as a dependency. (Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else)
> Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else
It is definitely not the de facto solution for open source. After using CMake as a C++ developer, I will never use CMake again. I simply don't have time to write a program in a slow, stringly-typed, ad hoc DSL just to build my actual program.
About the container stuff specifically, I think the different solution provided here versus off-the-shelf Docker is not merely to be compatible with Bazel. Rather it looks like, from having used it modestly, an intentionally different way of thinking about container builds, aiming toward different performance characteristics that scale etc. I can't think of any reason you couldn't call the docker tools in a genrule()…
Docker's build system is really strange. The build cache assumes that your dependency tree is linear, and it will invalidate the build cache if any file dependency changes, but a `RUN apt install foo` doesn't invalidate the cache--it's just assumed that every RUN statement is idempotent. Further, the Dockerfile's COPY is close to worthless--if you want to import all of your repo's Python packages, you have to put the…
Strange doesn't begin to cover it :). It's just broken.
What about non-monorepos? At my company we have quite a few large-ish projects (consisting of ~5 published artifacts, LoC doesn't matter for my question, but maybe 100k per project?), but the problem is that we want different organizations to have access to different subsets of our projects... so we don't have a mono-repo?
It it possible to do some sort of conglomeration where we could bazel-all-the-things and still publish separate artifacts (jar's, deb's, etc.) for different purposes?
What about non-monorepos? At my company we have quite a few large-ish projects (consisting of ~5 published artifacts, LoC doesn't matter for my question, but maybe 100k per project?), but the problem is that we want different organizations to have access to different subsets of our projects... so we don't have a mono-repo? It it possible to do some sort of conglomeration where we could bazel-all-the-things and still…
You could import each thing as `http_archive`s or `git_repository` or `local_repository`s and use visibility to manage what projects are allowed to use what