
Bazel Release 1.0 - klodolph
https://github.com/bazelbuild/bazel/releases/tag/1.0.0
======
habitue
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 reimplementations. The rust packaging rules for
bazel reimplement a subset of cargo's features from scratch. The docker rules
reimplement image building from scratch (they don't actually use docker). The
(Google maintained) python rules shell out to pip, but it's got a ton of
problems, some packages are unbuildable, and it busts the cache constantly and
redownloads everything.

If you're using C++ or Java, I can heartily recommend Bazel as an improvement
to your current tool. If you're using anything else, hold off until the
ecosystem is more mature.

I can believe all of these reimplementations are worth it for hermeticity, but
I seriously doubt most shops need the extreme hermeticity Google does. It's a
thing that really matters at gargantuan scale.

~~~
mrighele
What are the reasons to prefer Bazel to Maven or Gradle foe Java? I know it is
supposed to be faster but on the other side last time i checked it it was much
more complex and time consuming (expecially compared to Maven). Are there
other good reasons?

~~~
oweiler
I think for Java projects Bazel is a very bad choice. Last time I've checked
it was not even able to resolve dependencies transitively. And I doubt that
it's faster than recent versions of Gradle.

~~~
swsieber
I very much doubt that it's faster than Gradle, but Gradle does do quite a bit
more than Gradle.

~~~
dikei
Bazel incremental build is much much faster than Gradle, if you follow the
one-package-per-build rule.

------
zegl
I've been using Bazel full time for over two years now to build
Java/Go/Containers/gRPC and everything in between, and I must really say that
it's one of the best tools that I've stumbled upon.

A huge congratulations to the Bazel team for shipping 1.0!

~~~
klodolph
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 declarative. In my mind, these fall
into two families: Gyp and Bazel (which includes Buck, Pants, Please.build,
and that new custom thing Chrome uses).

(And then there’s Ninja, which I appreciate for taking a good / useful
_subset_ of Make’s features and doing it really well.)

~~~
dickeytk
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 seeing anything amazing.

~~~
klodolph
I’ll take a stab at it, since I’ve done some migrations to Bazel (and also
_away from_ Bazel). The comparison to Make and makefiles is good because Make,
unlike some other build systems, is mostly declarative. Most of your makefile
is going to declare what the inputs and outputs are.

If you use Make long enough, there are some obvious improvements you want.
Multiple outputs, rebuild when options change, and easier cross-compiling are
the top ones. Various build systems attempt to add these features. In my mind,
Ninja is the only build system that added these features well, and it worked
because Ninja removed all the other features to focus on just the build
process (as opposed to specification / configuration).

If you think about these problems with Make, you realize that it kind of boils
down to one big thing: you want your build system to always rebuild when
necessary, and you want it to almost never rebuild when unnecessary. (Plus the
bit about cross-compiling.)

Other build systems rely on the developer writing the build scripts to just
“get it right”. Bazel is different because it sandboxes the rules to enforce
hermeticity. In Make, I can include "pear.h" which includes "orange.h", but
let’s suppose that "orange.h" is actually a generated source file… now, try
writing this out in a Makefile (if you’re a masochist, say you’re cross-
compiling). Yes, "orange.h" should be declared as an input to anything that
includes "pear.h", but in practice, developers are going to screw it up. At
that point you can end up with a build that uses two different versions of
"orange.h".

Bazel sandboxes the commands so that any rule not declared to depend on
"orange.h" will not be able to open "orange.h" at all. The process won’t see
the file at all.

This opens the door for all sorts of optimizations and query features that are
simply unreliable if you have to trust that human developers are writing the
rules correctly. These optimizations, for large projects, result in radical
build time improvements. For most build systems, a shared build cache would
come with a risk of bad cache entries, but with Bazel, the risk is
substantially lower. It’s also easier to get reproducible builds, which make
it _substantially_ easier to do certain types of auditing.

~~~
boris
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...](https://build2.org/build2/doc/build2-build-system-
manual.xhtml#intro)

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

~~~
boris
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.

~~~
rienbdj
I don't see how build2 can be in the same spirit as Bazel when it misses the
main advantage of Bazel

~~~
boris
I never said build2 is "in the same spirit" as Bazel (whatever that means). I
said it fixes the same problems as OP listed.

~~~
weberc2
> 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?

~~~
boris
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.

~~~
weberc2
Caching depends on a correct model of the dependency tree. If a dependency
isn't included in the model, then a non-hermetic tool will silently succeed,
incorrectly while a hermetic tool will do the correct thing and fail the
build. Keeping the model accurate is too hard for humans, so in practice, non-
hermetic build tools can't cache correctly.

------
miles_matthias
Woo hoo! I got to spend a few days with the Bazel team in the NYC office a few
weeks ago and they were really excited about this announcement coming out
soon. Congrats!

One of my favorite uses of Bazel is in CI/CD. I built a demo which builds the
applications, creates Docker images, and then applies a K8s manifest to a
cluster. It's OSS now under the GCP handle:
[https://github.com/GoogleCloudPlatform/gke-bazel-
demo](https://github.com/GoogleCloudPlatform/gke-bazel-demo)

Happy to answer any questions, public or private (email / website in bio).

~~~
etxm
Does it work with VB6?

~~~
m0zg
You jest, but you could totally write the rules for it to support VB6.

------
ihnorton
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?

~~~
dgellow
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)

~~~
jchw
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.

~~~
pjmlp
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.

~~~
jchw
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.

~~~
pjmlp
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.

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

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

~~~
jchw
OK, ping me in 3 years.

~~~
pjmlp
Surely. I have seen too many carriages drive by.

~~~
jchw
Actually, there’s already an excellent Meson plugin for VSCode, and a pretty
good one for Qt Creator, so I hope you’re a fan of losing bets :p

~~~
pjmlp
So far, everyone that has bet against CMake has lost to overtake it.

Scons, qmake, waf, premake, Gradle C++, MSBuild, ...

I know which horse to bet on.

~~~
jchw
Scons and qmake both predate CMake. It’s weird to characterize them as trying
to “overtake” CMake; that’s not really a thing I think happened. As a matter
of fact, there was a time when qmake was a better option; it was a fairly
complete Makefile generator that had good support for subprojects and out of
tree builds.

Then again, this is all irrelevant. What these projects all had to offer at
one point is historical. Qt has to leave qmake because of qmake. During that
time they evaluated many options, including a fairly innovative design called
qbs - Qt Build System. In the end, the choice of CMake makes a lot of sense,
as it is clearly the best available choice that had ecosystem support. Qt is
unlikely to switch build systems again soon.

This entire argument has happened before, but instead of meson vs CMake it was
CMake vs autoconf. The thing is, I suspect CMake will still exist even as
Meson inevitably continues to gain traction, just as autoconf (unfortunately)
exists today.

There is, in fact, room for more C++ build systems, and almost definitely room
for better interop. (Meson and CMake have some interop today.)

------
hsivonen
How’s Bazel documentation these days for people who haven’t worked at Google?

In April 2018, I tried to do a quick port of a tiny gsl::span-using toy app to
absl::span, but I gave up, because Abseil wanted me to build my app using
Bazel and Bazel docs seemed to assume that I already have some context that
Googlers would have but I hadn’t.

(I emphasize that this was a _quick_ attempt at a toy program and not about
making a serious time investment to learn a tool for a serious project.)

~~~
grandmczeb
This is a legitimate criticism I hear even from new Google employees; Bazel's
documentation is pretty hard to read unless you already know a lot of its core
concepts, unfortunately.

------
Quekid5
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?

~~~
lhorie
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

~~~
Quekid5
Just trying to understand... so we would have ~5 (going by my original example
figure) Bazel builds and then use "imports of published things" to have
projects that depend on each other work?

~~~
lhorie
You would have 5 workspaces. How they work together is sort of up to you.

If you use `local_repository`, then you can link whatever's checked out from
version control together. This can be dangerous since there's nothing that
enforces what version of what works with what, but it's helpful for example,
if you want to beta test a new version of a ruleset in a workspace that
consumes it.

If you want to be strict about publishing artifacts and versioning, then
`http_archive` is the way to go. You can choose your publishing schedule and
other workspaces can independently manage which versions of the published
artifacts they want to use.

`git_repository` is a middle ground if you don't want the hassle of publishing
versioned artifacts, since it lets each workspace reference specific commit
SHAs for the things they import.

~~~
Quekid5
Thanks. Things may have changed since the last time I investigated Bazel --
I'll read up on this stuff.

I'm actually currently leaning towards something like Nix or Guix just because
it _really_ encompasses everything...

~~~
lalaithion
Nix is good for inter-package dependencies, while Bazel is good for internal
dependencies. You could use Bazel to build your packages for Nix, and import
your other projects into your BUILD files with
[https://github.com/tweag/rules_nixpkgs](https://github.com/tweag/rules_nixpkgs).

------
setheron
I really want to use it but anything beyond the simple example is difficult to
migrate to. I must have read the toolchain pages 10x times but still setting
up a custom compiler or even different JDK setup is confusing.

~~~
beisner
From what I have heard, the toolchain story is being worked on heavily. There
are some legacy reasons why toolchains were designed the way they were (mostly
due to the fact that Google essentially only uses one compiler for each
language, and certain toolchains were implemented natively instead of as
plugins), but the confusing semantics are improving! Maybe give it another
shot in 6-12 months.

------
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?

~~~
wasyl
> completely undocumented tool

Gradle is far from "completely undocumented". Unless you mean Android Gradle
Plugin, which surprisingly _is_ somewhat documented, although the docs are
tough to accidentaly just stumble by

~~~
aidenn0
I was actually refering to Soong not Gradle. Soong has been replacing
makefiles since android 7. Given that incremental builds are more of a
"hopeful aspiration" rather than "something that actually works" in Android 6,
I can't blame them too much for doing a major reworking.

------
zulu_lefty
many bigots here dismiss bazel out of hand for being written in java.

the binary ships it own JRE and starts instantly (uses a server), why is java
an issue exactly??

------
steeve
I've been using it for over almost two years on a 5 languages iOS/Android
project, and then on everything I could. Congrats to the team!

~~~
wasyl
Nice! I've been considering trying out Bazel for an Android project but didn't
get around to it yet. How is the IDE support (Android Studio and/or IntelliJ)?
And how is actual Android support in Bazel, for example in terms of feature
modules, app bundles, DataBinding (that I guess is supported as a regular
annotation processor) and third party plugins like Firebase? How much of a
dealbreaker is it if I have to use a complex 3rd party Gradle plugin that I
wouldn't want to rewrite for Bazel?

------
The_rationalist
How does bazel compare to
[https://github.com/microsoft/vcpkg/blob/master/README.md](https://github.com/microsoft/vcpkg/blob/master/README.md)
And
[https://github.com/microsoft/BuildXL](https://github.com/microsoft/BuildXL) ?

------
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...](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-
swift.html)

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

[https://github.com/bazelbuild/rules_swift](https://github.com/bazelbuild/rules_swift)

[https://github.com/bazelbuild/rules_apple](https://github.com/bazelbuild/rules_apple)

~~~
steeve
We (Zenly) are, it works well!

------
neves
My company uses Java and Javascript, our build system is Maven. It starts the
npm/yarn build process. We have hundreds of projects in it.

I don't like the tooks, but would it be worth the trouble to change to Bazel?

~~~
klodolph
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 rules for TypeScript +
Rollup to create bundled JavaScript files. Bazel’s TypeScript rules execute
much faster than running tsc from the command line because someone took the
time to figure out how to keep a hot copy of tsc running that Bazel can send
commands to.

My personal experience is that you can do a gradual migration by working
bottom-up, starting with the components that have no dependencies. There is a
learning curve to it if you are the one writing rules, and it can take a while
to get the hang of it / find where the good resources are.

I would evaluate it on an estimated cost/benefit basis. The primary benefit
for large projects is build times. If you can quantify how much time your
developers are spending waiting for builds, and estimate how much time you can
cut off with Bazel’s shared caches, you can guess how quickly it will pay off
or whether it will pay off at all.

If nothing else, you can find a leaf dependency somewhere in your projects and
write some quick BUILD files for it. That shouldn’t take very long, if you
have a half-day or day to spare.

~~~
gfunk911
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.

~~~
klodolph
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 mess I remember going through with
TypeScript back when you had to write a lot of your own types for libraries
you used.

~~~
gfunk911
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.

------
random3
I wonder how / if Bazel will integrate wit Google Cloud Build. IMO that should
be an end goal for a tool like Bazel. At a first glance, they are (highly)
incompatible. 1\. Bazel's statefulness is a core feature while GCB is
stateless. 2\. They both need to control things holistically to work (or you
lose advantages otherwise).

So in order to benefit from the two, it would likely require GCB to work with
Bazel natively and also to have some powerful state abstractions in order to
optimize builds in a distributed fashion.

~~~
the-rc
There's a hosted Bazel in an early access preview. Tensorflow uses it.

~~~
random3
Thank you! Would love to try that. How to access pre-release?

~~~
orbz
Just use it in your cloudbuild.yaml file:
[https://github.com/GoogleCloudPlatform/cloud-
builders/tree/m...](https://github.com/GoogleCloudPlatform/cloud-
builders/tree/master/bazel)

------
amrox
The only contact I’ve had with bazel is via Tensorflow (more specifically tf
lite). Last I tried it was not possible to set up bazel to output a static
library. Has this changed?

~~~
steeve
It should be:

    
    
        --dynamic_mode=off

------
adev_
I am going to be hated and downvoted for that but let's go...

Bazel, like Bucks and other, try to bring on table a build system / deployment
system that is multi-language, multi-platform and developer oriented. A holy
Graal that many developer ( like me ) looked for decade and that many (large)
organizations more or less tried to do one day (and most failed)

It is a good idea. It is a required tool to improve productivity. However, if
the idea is good on paper, in the implementation, Bazel is damn wrong.

\- Bazel is centered around "mono-repo" culture, making it much harder to
integrated with multi-source, multi-repo, multi-version projects like many of
us have. If I have no doubt that it is great at Google, the external world is
not google.

\- Bazel is made in JAVA, requires the JVM and this is a problem. That make
Bazel not a "light" tool easy to deploy in a fresh VM or in a container.

\- Bazel mix the concepts Build System ( like Make, ant, co ) and Deployment
System like ( rpm, pkgsrc, etc). That makes Bazel pretty hard to integrate
with projects that have existing build system, and almost impossible to
integrate _INSIDE_ an other Deployment System (usual package manager,
deployment pipeline). The problem that Bazel faces with some languages (
python, go ) is a cause of that.

\- Bazel venerates and follows the cult of "DO NOT INSTALL": compile and
execute in workspace, there is no "make install", not installation phase. If
"convenient" in mono-repo, this is often a nightmare because the boundary
between components can be easily violated... and you finish by having many
project that use internal headers or interface.

\- Bazel makes mandatory ( almost ) to have internet to compile. This is a
problem, a major problem in many organization (like mine) where downloading
random source and binary from the Web is not acceptable for security reasons.
Try to run Bazel in a sandbox.... and cry.

\- Related to what I said before, Bazel mixes Build system and Deployment
system. Doing so, it makes the same mistake that many "language specific"
package manager and make uselessly hard to depend on an already installed,
local library / component.

\- And finally, last but not least... The options.... Bazel throw away 30
years of conventions / naming from the ( GNU / BSD world ) to create its
own.... That make the learning curve difficult... Specially with a (up to
recently) very sparse and outdated documentation.

I have no doubt that inside Google or Facebook, Bazel or Bucks are amazing.But
they have been released too late for the external world in my mind.

Nowadays platform independant package managers like spack
([https://github.com/spack/spack](https://github.com/spack/spack)), Nix
([https://nixos.org/nix/](https://nixos.org/nix/)), GUIX
([http://guix.gnu.org/](http://guix.gnu.org/)) gives 95% of the advantages of
Bazel without the pains of it.

~~~
cromwellian
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 already installed stuff. Toolchains already provide a way to do
this, and the android_sdk_repository rule literally requires preinstallation.

Seems to me your making a lot of claims about bazel without having used it.

~~~
adev_
> 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...](https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/)

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
complained. Fixes that were sometimes not even documented.

~~~
cromwellian
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.

------
thundergolfer
I’m maintaining an example polyglot Bazel-built monorepo if anyone wants to
follow Bazel’s progress.

I aim to follow best practices and mark out any undocumented gotchas.

[https://github.com/thundergolfer/the-one-true-bazel-
monorepo](https://github.com/thundergolfer/the-one-true-bazel-monorepo)

------
mosselman
What is it? What can I use this for?

~~~
paulddraper
Polyglot build system (a la make), designed by Google for large code bases
with:

* Assured reproducibility via sandboxing

* Distributed caching

* Distributed execution (experimental)

* Support for long-lived worker processes

* Static analysis of build dependencies

* Uniform CLI for builds and tests

Build definitions and extensions are written in Starlark, a subset of Python.

If you work in a large repo, especially one with multiple languages, you
should be interested in Bazel.

Many of Google's OSS projects now build with Bazel (TensorFlow, K8s, Angular).

Buck and Pants are similar tools by Facebook and Twitter respectively,
inspired by Bazel's closed source predecessor Blaze.

------
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.

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

------
kronin
Does anyone have experience building graalvm native images with Bazel? Or
quarkus more specifically?

~~~
jingwen
There are Bazel rules for Graal:
[https://github.com/andyscott/rules_graal](https://github.com/andyscott/rules_graal)

------
rad_gruchalski
Am I correct in thinking that Bazel is a fantastic fit for golang with
modules?

~~~
zapita
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](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.

~~~
habitue
Yeah, I think the heuristic should be "Am I forced to migrate to bazel to
solve real problems my company is having?"

Vs.

"Can I migrate because bazel is the new thing"

------
rjsw
Is it any easier to port to different operating systems than earlier versions
?

------
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.

------
haolez
Is there something to gain from Basel on small projects?

~~~
kevincox
Not as much. But quality cache invalidation and high level project
descriptions are always nice.

------
whoevercares
Brazil blaze and bazel, someone should tell the story

------
pnako
Hundreds of developers around the Googleplex rejoice.

~~~
dickeytk
Isn’t Bazel based off another tool they use internally?

~~~
klodolph
Yes. My guess is that over a long enough period of time, the internal build
system will migrate to Bazel. But I don’t think it will happen soon. Large
migrations are always a pain, but Bazel does make it easier (since you can
isolate dependencies very well and migrate bottom-up).

I don’t work there, but I have talked to Googlers working on build systems.

~~~
evmar
Bazel is just the open source name of the internal Google build system, it is
the same codebase.

~~~
klodolph
From what I understand, the two tools have some very significant differences
at this point. They may be the same codebase in a broad sense, and may share a
lot of code, but I bet they are using something like Copybara to synchronize
them.

[https://github.com/google/copybara](https://github.com/google/copybara)

