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

51–60 of 180 posts

Re: Bazel Release 1.0

#51

Post by jchw »

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)

CMake may have a longer history of being used by open source, but Meson has been growing in popularity for some important projects. I definitely prefer Meson to CMake.

Bazel is also a great build system, but yeah, the JRE dependency will obviously make it less desirable for some users. Still, I hope people consider it anyways, because its focus on correctness is pretty great.

Re: Bazel Release 1.0

#52

Post by throwaway13372 »

The story would be much promising if Google bought github.

Unfortunately, bazel's future is significantly complicated because of the lack of a repo partner in the ecosystem.

In short, a true single repo experience with bazel would be easily 10x the current one.

Re: Bazel Release 1.0

#53

Post by SolarNet »

dickeytk wrote: post #15
klodolph wrote: post #13

Earlier quoted context omitted.

It really is that good. I’ve been using it only over a year, but I’ve done a lot of build system work with different tools and Bazel stands out. Most other tools seem to be competitors to Make (SCons, Jam, tup), souped-up scripting systems (Ant, Gradle), or configuration toolboxes (CMake). The ones that really stand out are the tools that tackle the problem of expressing builds in a way that’s both expressive and dec…

I use bazel at work heavily in a very large project. I’ve always worked with scripting languages so I’m much less familiar with build systems. I’m not sure I get what makes bazel so good. It seems pretty simple to me. You have a bunch of directories with BUIILD files that are each sort of like Makefiles. Am I missing something? It kind of just seems like a hodgepodge of scripts. I don’t dislike it, but I’m also not s…

You get a lot of features for very cheap compared to other systems. That's the best way I can describe it.

Bazel is basically cross platform out of the box if one is careful with it: that includes a consistent build organization across platforms, cross builds if configured, and so on. It can build a library declaration for mobile and desktop and embedded and web in a single workspace; try that with CMAKE.

Bazel has a universal package system (e.g. download an archive or git repo) that allows for custom ecosystems (yes some of which are not great yet) to exist regardless of what is normal that ecosystem. This is especially notable for C++ where using CMAKE as a package system is a nightmare, with bazel I can just download any C++ repo off the internet and ignore it's CMAKE file for my own BUILD file. Also notably it's the first build system for C++ that hasn't required me to build or configure boost myself, someone can run bazel build against a repo of mine with boost in it without even knowing what boost is and it just builds.

Which brings me to hermeticy and reproducibility. If one is careful running bazel it always uses the same code for a platform (I've never had or seen weird "on my machine" issues with it which is impressive; reverting/stashing changes has always gotten people a working build again). All of the sources are version pinned, and so on. Getting to hermetic takes some work, but it's possible which is nice. A side effect of all this is my instructions for a bazel project are usually: install bazel, run build; and it just works! Yes parts of the ecosystem suck and break this, but that's a work in progress.

There are other features, like the query system, the test runner, the macro system, the local override idiom, the parallel build. The point is it really is a build tool for whatever needs to be built, however it needs to be built, and not just a scripting language useful for building things.

Re: Bazel Release 1.0

#54

Post by Unknoob »

I've looked at Bazel some time ago but it was lacking full Swift support. There's some mentions to Swift scattered across the docs but some of them lead to 404 pages[1].

Has anyone gotten a Swift + Objective-C project running on Bazel or should I stay with Facebook's Buck?

[1]: https://github.com/bazelbuild/rules_apple/blob/master/doc/ru...

Edit: Found the correct links for the Swift/Apple support docs.

https://github.com/bazelbuild/rules_swift

https://github.com/bazelbuild/rules_apple

Re: Bazel Release 1.0

#55

Post by miles_matthias »

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're really excited about 1.0 for this reason, they're tired of breaking other people's builds too. The goal is to limit that with the 1.0 release, so expect this to get a lot better.

Re: Bazel Release 1.0

#56

Post by kylecordes »

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…

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() though, if you prefer.

Re: Bazel Release 1.0

#57

Post by Too »

klodolph wrote: post #39
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…

> The reason the ecosystem maturity is so important for bazel is because its design encourages complete reimplementations. My experience from before Bazel is that reimplementations were the way to go most times you had projects with multiple languages, because the alternatives lead you down dark paths—calling into a separate build system suffers from the same problems as recursive make. What excites me about 1.0 is t…

It would be neat if all build systems had a standardized way to return their dependency graph (like gcc -MD) so they can be used recursively by other build systems. I'm not aware of any that does and there's far from a standard which allows easy chaining of multiple different sub build systems. Which unfortunately either leads to recursive make, remodeling the dependencies in two places or forcing everything into the same build system.

Re: Bazel Release 1.0

#58

Post by kylecordes »

miles_matthias wrote: post #55
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're really excited about 1.0 for this reason, they're tired of breaking other people's builds too. The goal is to limit that with the 1.0 release, so expect this to get a lot better.

I follow some of the relevant repositories, and there has been a big effort over the last few months to get many many loose ends cleaned up, toward a stable set of tools that will change in a predictable cadence without undue breakage.

Re: Bazel Release 1.0

#59

Post by kylecordes »

ufo wrote: post #18
klodolph wrote: post #13

Earlier quoted context omitted.

It really is that good. I’ve been using it only over a year, but I’ve done a lot of build system work with different tools and Bazel stands out. Most other tools seem to be competitors to Make (SCons, Jam, tup), souped-up scripting systems (Ant, Gradle), or configuration toolboxes (CMake). The ones that really stand out are the tools that tackle the problem of expressing builds in a way that’s both expressive and dec…

In the topic of classifying build systems, there was a really interesting paper about that published at ICFP last year https://blogs.ncl.ac.uk/andreymokhov/build-systems-a-la-cart... They classify it based on how the build system detects what needs to be rebuilt and how the build system chooses the order things should be built in

I'd like to get a good grasp of the differences between Bazel and Buck. I've used the Bazel but not Buck - most descriptions of Buck describe it as being pretty similar to Bazel. (Also, that's a very interesting paper, will read in depth.)

Re: Bazel Release 1.0

#60

Post by habitue »

kylecordes wrote: post #56
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…

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
Post reply on HN