Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bazel Release 1.0

github.com

Post reply on HN
Print view View original

61–70 of 180 posts

Re: Bazel Release 1.0

#61

Post by geodel »

pjmlp wrote: post #14
echelon wrote: post #7

Earlier quoted context omitted.

Bazel is here to stay. Sooo many companies are jumping on this bandwagon [1]. Bazel is better than Maven, Pants... you name it. Think of this like Protobuf or Kubernetes. It's an open source tool used to build things at scale. There will be lots of users and contributors. A cottage industry will spring up, and this will grow well beyond Google. [1] https://github.com/bazelbuild/bazel/wiki/Bazel-Users

If only Android team cared to use it instead of Gradle. Android is probably the only platform where almost at every conference there is a regular talk on how to improve build times. Not even C++ conferences talk so much about build times.

I find gradle is something like doing thing diligently what should not be done in first place. It seems clear though Oracle/OpenJDK have no interest in putting some fucking options in `javac` itself to compile project/module or even package. Users must wade through maven/gradle crap every time even to compile pure Java projects.

Re: Bazel Release 1.0

#62

Post by henryaj »

dgellow wrote: post #25
ihnorton wrote: post #22

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)

Please[0] is a Bazel-like build system written in Go.

[0] http://please.build/

Re: Bazel Release 1.0

#63

Post by aidenn0 »

If android switches to bazel now that bazel is 1.0 does that mean we can switch from a completely undocumented tool to a poorly documented tool?

Re: Bazel Release 1.0

#64

Post by gfunk911 »

klodolph wrote: post #40
gfunk911 wrote: post #34

Earlier quoted context omitted.

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.

To be honest I had written some custom build systems and spent extensive time working on the problem. So a lot of the Bazel features made me go “aha” because they solved a problem I recognized—but the features seem weird if you don’t recognize the problem you’re solving. What helps is to understand the separate phases of the Bazel build process and look at other Bazel repositories. To me it’s not as bad as e.g. the m…

Thanks for the reply.

A bunch of the problems I had might be due to out of date js tools, since apparently Bazel has been breaking compatibility a lot pre 1.0. Things I pull from the docs of the main js/ts bazel libraries are more likely to error than work. Will wait a while for things to catch up now that it's 1.0 and check back in next year or something.

Thanks again.

Re: Bazel Release 1.0

#65

Post by KerrickStaley »

aidenn0 wrote: post #63

If android switches to bazel now that bazel is 1.0 does that mean we can switch from a completely undocumented tool to a poorly documented tool?

Bazel documentation is fine from what I've seen. Moreover if you ask questions on Stack Overflow, members of the Bazel team will often respond (kudos especially to László for his support on SO).

Re: Bazel Release 1.0

#66

Post by lhorie »

habitue wrote: post #35

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…

> They've been breaking backwards compatibility constantly

I maintain a ruleset and have been on top of Bazel upgrades for a few months. My experience hasn't been so bad. There definitely are a lot of deprecations, and some code changes required, but it was pretty manageable IMHO.

With that said, I agree that some stacks are more first class citizens than others. But I feel this is more due to some stacks' departure from the C++ style of build management than an issue of Bazel changes. At our company, the Go org has had a pretty good experience with migrating from Buck to Bazel. For our web org, the main challenges have been that Bazel doesn't really lend itself well to dealing with codebases where inputs and outputs co-exist in the same filesystem tree (and this is incredibly common in the web world with things like babel transpiled files, yarn offline caches, lerna, etc) or where the ecosystem has a bad relationship with symlink handling (e.g. jest, flow, webpack, --preserve-symlinks, etc)

Re: Bazel Release 1.0

#67

Post by boris »

skybrian wrote: post #43
boris wrote: post #30

Earlier quoted context omitted.

Bazel (and Bazel-derivatives/alikes) is not unique in fixing all of these problems. For example, there is build2, which is arguably a lighter-weight and closer to make (in spirit, not in syntax) solution (no Java dependency, etc). Here is an intro, if anyone is interested: https://build2.org/build2/doc/build2-build-system-manual.xht...

I did a quick skim and it doesn't seem to sandbox the build steps like Bazel? Maybe I missed something.

It doesn't do Bazel's style sandboxing where your entire compiler toolchain is part of your build system. It does what we call high-fidelity builds: it tracks changes not only to inputs but also to compile options, compiler itself (checksum), environment, etc., and if any of these auxiliary dependencies change, it triggers a rebuild. There are advantages and disadvantages to both approaches with build2's being lighter weight.

Re: Bazel Release 1.0

#68

Post by adev_ »

ihnorton wrote: post #22

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?

> I hope that this 1.0 status will prompt the Qt people to take a closer look at Bazel

By the sake of God no.

The last thing I need to compile Qt is a gigantic framework requiring the JVM. Plus the fact Bazel has so many side effect that that even quantum physics experiments looks more reproducible: Just try to compile tensorflow and enjoy the fun.

Stick to CMake, thanks.

Re: Bazel Release 1.0

#69

Post by boris »

klodolph wrote: post #50
boris wrote: post #30

Earlier quoted context omitted.

Bazel (and Bazel-derivatives/alikes) is not unique in fixing all of these problems. For example, there is build2, which is arguably a lighter-weight and closer to make (in spirit, not in syntax) solution (no Java dependency, etc). Here is an intro, if anyone is interested: https://build2.org/build2/doc/build2-build-system-manual.xht...

It would be interesting to see how build2 achieves these things (hermeticity, cross-building, shared caches). I can’t see anything in the linked documentation that mentions these problems at all.

It currently doesn't do fully hermetic configurations (as in, where it is impossible for any inputs to come outside of the project). Instead build2 does high-fidelity builds where it makes sure that if any of the inputs change (including options, environment, compiler itself, etc), the target gets rebuilt. See my reply to a sibling comment for some details. We do plan to add support for hermetic builds though it won't be exactly like Bazel's -- the idea is to prevent and, where not possible, detect external changes and fail rather than rebuilding.

Regarding caching (and distributed compilation), this is currently on the TODO list though a lot of the infrastructure is already there. For example, the same change detection that is used for high-fidelity builds will be used to decide if what's in the cache is usable in any particular build.

While I agree we should mention these points in the documentation (things are still WIP on that front), I don't think cross-compilation deserves mentioning: for any modern build system it should just work. In build2 we simply implement things in the "cross-compile first" way, with native compilation being a special case (host == target).

Post reply on HN