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

161–170 of 180 posts

Re: Bazel Release 1.0

#161

Post by cromwellian »

adev_ wrote: post #153
cromwellian wrote: post #137

Earlier quoted context omitted.

1) bazel can be built with a self contained bundled paired down jvm, and possibly an executable using GraalVM but I don’t know anyone who tried that yet. 2) bazel can do offline compiles, and is actually built to run in sandboxes 3) bazel can act as a build system only and delegate to externa package managers Look at rules_nodejs for example and the managed_directories + yarn_install/npm_install rule 4) depend on alr…

> Seems to me your making a lot of claims about bazel without having used it I lost literally weeks of my life to make Bazel work in external build systems for tensorflow and others. And I am apparently not the only one : https://archive.fosdem.org/2018/schedule/event/how_to_make_p... Then I don't allow you to tell me "not having used it". All the answers you gave are "fixes" that have been made after the community c…

Bazel is based on Blaze, which is Google's internal mono repo build system. But Angular, Kubernetes, Tensorflow, et al, are open source projects, Angular in particular, needs to work with NodeJS and Typescript ecosystems, which almost immediately demands dealing with node_modules dependencies if Bazel is to be used with it. You see to imply this was a case of Bazel folks somehow being blind sided by these requirements, but it's more a case that step 1 was to make a version of Blaze that works outside Google, step 2 was to make it work for non-monorepos and non-single-version dependencies, and step 3 was to make it integrate with alien package management ecosystems.

Actual support for the things you claimed is quite good now, and that's my point. You posted a number of claims that are now no longer true as of version 1.0. Yeah, a year ago, things were bad, but then again, it was a project at beta level in rapid development, and pretty much for early adopters.

Re: Bazel Release 1.0

#162

Post by mrath »

One big pain point for bazel is installation on Windows, it needs msys2 and need it on the default path. Just a pain to setup. I was thinking of proposing bazel in my org, but after my try on work laptop I abandoned the idea.

Re: Bazel Release 1.0

#163

Post by weberc2 »

adev_ wrote: post #156
weberc2 wrote: post #136

Earlier quoted context omitted.

I get not wanting a JVM (although all else equal I’ll take the JVM dependency any day over CMake), but how is CMake _more_ reproducible than Bazel? The latter builds in a clean room, Make does not.

> how is CMake _more_ reproducible than Bazel? Because CMake contrary to Bazel do not break its retro-compatibility in its options and config every two minor versions ? > The latter builds in a clean room, Make does not. Sandboxing should be the concern of the package manager / deployment pipeline, Not the build system concern. That just makes things redundant and painful to debug.

> Because CMake contrary to Bazel do not break its retro-compatibility in its options and config every two minor versions ?

Lol that’s only recently true. CMake was infamous for breaking compatibility. Anyway, Bazel was pre-1.0 until just now, so of course expect some instability.

> Sandboxing should be the concern of the package manager / deployment pipeline, Not the build system concern. That just makes things redundant and painful to debug.

It makes things specifically very easy to debug. Not everyone enjoys troubleshooting issues on their machine due to their local environment.

Re: Bazel Release 1.0

#164

Post by jchw »

pjmlp wrote: post #160
jchw wrote: post #51

Earlier quoted context omitted.

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.

Unless Meson gets to support all the toolchains and OS supported by CMake, and the existing plugins eco system it is non starter. Meson will most likely be kept as the GTK, GNOME build system.

Non-sense. It only needs to support the toolchains and OSes people actually want, by no stretch of the imagination does it have to support all of the same stuff CMake does. It is not a non-starter for many.

It is the build system of lots of projects already, not just GNOME but also freedesktop stuff too, libinput is one.

Re: Bazel Release 1.0

#165

Post by dastbe »

m0zg wrote: post #147
dastbe wrote: post #146

Earlier quoted context omitted.

So bazel and brazil solve similar but very distinct problems. bazel is solving the problem of fast, repeatable, "bulletproof" builds for (very large) monolithic repos, whereas brazil is solving for fast, repeatable, "bulletproof" builds for (very large) collections of repositories or packages. brazil is EXTREMELY agnostic to what happens within any given package build, with the associated tooling primarily focused on…

Google just tests the living Jesus out of everything, and only versions a few core packages such as protobufs, grpc, and other packages used by pretty much everybody (this is called the "crust"). Everything else is tip of tree, and things are automatically re-tested using checked-in tests if they are affected by your changelist. You basically can't submit if you break anything. So in a way, Google doesn't need "versi…

> Blaze (at Google) is also not just a build system, but also an interface to a much larger distributed build and test backend, which lets you rebuild everything from the kernel upwards in seconds (by caching petabytes of build products at thousands of possible revisions), serves up source code views for developer workstations (code is not stored there either), and sustains the scale of distributed testing needed for this setup to work. As a result, nobody builds or tests on their own workstation, and there's close to zero (or maybe even zero, period) binaries checked into Google3 monorepo. If you need a Haskell compiler and nobody used it in a while, it'll be rebuilt from source and cached for future use. :-)

The distributed, cached builds are effectively the same thing for Brazil (at the package level), with applications, libraries, system packages, all the way down to compilers being built from source. Brazil doesn't have the level of file system abstraction that Blaze/Bazel does, and prefers towards local development using overlays version sets for certain core build tools.

>Fundamentally, I think Google got things very, very right with Blaze. Bazel is but a pale shadow of what Blaze is, but even in its present state it is better than most (all?) other build systems.

I think Bazel gets things amazingly right for a single monorepo even w/o all of the fanciness that comes from internal systems and services, but the mechanisms for managing out of source dependencies is just flat out clunky. I suspect this is because Blaze never had to really solve that problem, and I think Brazil is a much better tool for solving it because it's what it had to do.

Re: Bazel Release 1.0

#166

Post by pjmlp »

jchw wrote: post #164
pjmlp wrote: post #160

Earlier quoted context omitted.

Unless Meson gets to support all the toolchains and OS supported by CMake, and the existing plugins eco system it is non starter. Meson will most likely be kept as the GTK, GNOME build system.

Non-sense. It only needs to support the toolchains and OSes people actually want, by no stretch of the imagination does it have to support all of the same stuff CMake does. It is not a non-starter for many. It is the build system of lots of projects already, not just GNOME but also freedesktop stuff too, libinput is one.

That is not how adoption at scale works.

Everyone on C++ community is gravitating towards CMake, Conan and vcpkg, they won't migrate to something else now.

Re: Bazel Release 1.0

#167

Post by meisterT »

mrath wrote: post #162

One big pain point for bazel is installation on Windows, it needs msys2 and need it on the default path. Just a pain to setup. I was thinking of proposing bazel in my org, but after my try on work laptop I abandoned the idea.

It doesn't require msys2 anymore, so you might want to try again.

Re: Bazel Release 1.0

#168

Post by jchw »

pjmlp wrote: post #166
jchw wrote: post #164

Earlier quoted context omitted.

Non-sense. It only needs to support the toolchains and OSes people actually want, by no stretch of the imagination does it have to support all of the same stuff CMake does. It is not a non-starter for many. It is the build system of lots of projects already, not just GNOME but also freedesktop stuff too, libinput is one.

That is not how adoption at scale works. Everyone on C++ community is gravitating towards CMake, Conan and vcpkg, they won't migrate to something else now.

Yes it is. CMake was adopted long before it supported everything it supports today.

Re: Bazel Release 1.0

#169

Post by pjmlp »

jchw wrote: post #168
pjmlp wrote: post #166

Earlier quoted context omitted.

That is not how adoption at scale works. Everyone on C++ community is gravitating towards CMake, Conan and vcpkg, they won't migrate to something else now.

Yes it is. CMake was adopted long before it supported everything it supports today.

Let us know when Meson gets first class support on Eclipse CDT, Clion, Qt Creator, KDevelop, Android Studio, VSCode and Visual Studio.

Re: Bazel Release 1.0

#170

Post by jchw »

pjmlp wrote: post #169
jchw wrote: post #168

Earlier quoted context omitted.

Yes it is. CMake was adopted long before it supported everything it supports today.

Let us know when Meson gets first class support on Eclipse CDT, Clion, Qt Creator, KDevelop, Android Studio, VSCode and Visual Studio.

OK, ping me in 3 years.
Post reply on HN