15 ms·

Bazel Release 1.0

263 points by klodolph 7y ago

pnako 7y ago
Hundreds of developers around the Googleplex rejoice.
- dickeytk 7y ago
  Isn’t Bazel based off another tool they use internally?
  - Spinfusor 7y ago
    Yes: the internal tool is Blaze
  - klodolph 7y ago
    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.
    - ses1984 7y ago
      I want to try this with a monorepo codebase now but every time I try to get started I feel overwhelmed. I'm trying to sell my team on it, but none of us has experience with bazel. I'm trying to figure out how to do a small poc where we migrate one intermediate thing in the monorepo to bazel and try to prove out how it can take over everything.
      - klodolph 7y ago
        I have personally done this. - You are going to screw things up a couple times. The documentation for Bazel is not always clear, but you can usually find examples or explanations of complicated stuff on forums somewhere. - Start with a leaf dependency, something in your codebase that doesn’t depend on anything else. Then work your way up. Just write a WORKSPACE + BUILD.bazel in your root, and then put a BUILD.bazel in the directory for the dependency you are going to work on. - Look at examples like Tensor Flow, especially for how to handle third-party dependencies (although Tensor Flow is going to do it in a more complicated way). - Migrate your tests as you go. - Just run "bazel build //...:all" or "bazel test //...:all" from your project root as you go to make sure things don’t break. - Undoubtedly it will take a while to develop a good mental model of how Bazel works. For fun, try looking around in the output directories, or look at the sandboxes it creates.
        ses1984 7y ago
        I appreciate your help and was curious if you could field one more specific question: What if I wanted to fork tensorflow and integrate my project into it, would I need the tensorflow fork as something like a git submodule in my main repo, or is there a way to tell bazel there's another repo somewhere else and where it fits into the graph?
    - evmar 7y ago
      Bazel is just the open source name of the internal Google build system, it is the same codebase.
      - klodolph 7y ago
        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
orangepanda 7y ago
Did they announce the deprecation date as well? https://killedbygoogle.com/ https://killedbygoogle.com/
- javagram 7y ago
  It’s OSS software not a SaaS. If people use it there will be no deprecation date. You can just fork and continue.
  - dgellow 7y ago
    I’m sorry if that sounds harsh, but that’s at best a naive view. In practice you cannot just fork the codebase and continue maintaining it, that has a high cost that a lot of organization cannot afford. It’s technically true that you can fork the project but in practice forking something that big doesn’t really happen without a big player leading the fork (or some motivated people with enough time and money to dedicate to the fork, which is possible but unlikely).
    - javagram 7y ago
      Hence the “if people use it” qualifier. Companies relying on Bazel would step in and support it. We’ve seen this play out plenty of times before, e.g. Hudson to Jenkins or OpenOffice to LibreOffice, where a popular OSS product loses a corporate sponsor and continues.
      - dgellow 7y ago
        You’re ignoring all those times where that didn’t actually happen. It seems quite risky for an organization to rely on the idea “you can just fork and continue the development yourself in case of issues”. That’s not what happens in practice, taking over the development of something like bazel has a non-negligeable cost. Now for sure you can find some (cherry-picked IMHO) success stories but that’s the exception as far as I can tell.
  - skybrian 7y ago
zegl 7y ago
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 7y ago
  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 7y ago
    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.
    - afthonos 7y ago
      My experience is that I realized the value when I switched to a project that didn’t use it. Especially when I wanted to use other Google technologies like protos, or when I wanted to incrementally rebuild dependencies. Disclosure: I work at Google, with Blaze, but not on it, or on Bazel. All opinions mine.
    - klodolph 7y ago
      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.
mosselman 7y ago
What is it? What can I use this for?
- klodolph 7y ago
  It’s a build system. That might not be very exciting to you, but for large projects and multi-language projects it is usually much better than other build systems. It is designed to help give you fast distributed builds with high shared cache hit rates, reproducible builds, and a lot of tools to analyze dependencies. Personally, I like using it any time a project starts using multiple languages, protobufs, or generated sources.
- paulddraper 7y ago
  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.
amrox 7y ago
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?
- Q6T46nT668w6i3m 7y ago
  IIRC, transitive C++ libraries are coming sometime this year.
- steeve 7y ago
  It should be: --dynamic_mode=off
neves 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.
ihnorton 7y ago
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 7y ago
  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)
  - ahartmetz 7y ago
    Qt is moving to CMake for Qt6, they are already working on it. Qt6 release is planned in a year or so.
    - dgellow 7y ago
      I’m aware, that’s why I mentioned it.
  - jchw 7y ago
    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.
    - berti 7y ago
      Last time I checked meson still doesn't have great Qt support e.g. it can't track rcc dependencies [0]. Funnily enough that issue is about rcc not making dependencies available to the build system, but I believe it actually started doing so somewhere down the track. I did a little work on it a couple of years back but regrettably never followed up [1]. [0] https://github.com/mesonbuild/meson/blob/27c01dff01832fa9d0c92602d0dc25b6ded9d2e9/mesonbuild/modules/qt5.py#L26 https://github.com/mesonbuild/meson/blob/27c01dff01832fa9d0c... [1] https://github.com/mesonbuild/meson/issues/97#issuecomment-329113396 https://github.com/mesonbuild/meson/issues/97#issuecomment-3...
habitue 7y ago
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.
- klodolph 7y ago
  > 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 the possibility that the third-party rules can mature. Its not too bad if you only need a couple sets of third-party rules but my experience is like yours-when a new Bazel release came out, you had to figure out when to upgrade based on your dependencies on third-party rules. If you had several of these, it made upgrading Bazel infeasible.
  - jonhohle 7y ago
    Amazon’s build system handled this gracefully. Native build tool chains were always used, but wrapped in a relatively thin facade. As long as the buildtool could respond to a `release` target and put artifacts in a well known location it didn’t matter what the underlying implementation was. The biggest drawback that I could see was all dependencies and tool chain needed to be modeled, but once they were, incremental builds, dependency rebuilds, etc. all Just Worked™. Getting to that point requires a lot of upfront work, however, which can be hard to justify in smaller groups.
setheron 7y ago
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 7y ago
  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.
miles_matthias 7y ago
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 7y ago
  Does it work with VB6?
  - m0zg 7y ago
    You jest, but you could totally write the rules for it to support VB6.
  - etxm 7y ago
    Don’t look down your nose at VB, snobs.
  - Gibbon1 7y ago
    Yeah we have a right to know
- kovek 7y ago
  That's cool, thanks Miles, I was looking at exactly this yesterday. I think I'll be able to finish figuring it out in the next few days when I have an hour or two.
rjsw 7y ago
Is it any easier to port to different operating systems than earlier versions ?
kronin 7y ago
Does anyone have experience building graalvm native images with Bazel? Or quarkus more specifically?
- jingwen 7y ago
  There are Bazel rules for Graal: https://github.com/andyscott/rules_graal https://github.com/andyscott/rules_graal
fuckyah 7y ago
one of the rabbit holes folks tend to get into is that bazel will magically solve their codebase problems. builds may be faster, but how about the IDE? most IDE's are not able to handel huge codebases well :/
throwaway13372 7y ago
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.
Unknoob 7y ago
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/rules-swift.html 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_swift https://github.com/bazelbuild/rules_apple https://github.com/bazelbuild/rules_apple
- steeve 7y ago
  We (Zenly) are, it works well!
aidenn0 7y ago
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?
- KerrickStaley 7y ago
  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).
- wasyl 7y ago
  > 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 7y ago
    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.
rad_gruchalski 7y ago
Am I correct in thinking that Bazel is a fantastic fit for golang with modules?
- zapita 7y ago
  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 7y ago
    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"
steeve 7y ago
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 7y ago
  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?
random3 7y ago
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 7y ago
  There's a hosted Bazel in an early access preview. Tensorflow uses it.
  - random3 7y ago
    Thank you! Would love to try that. How to access pre-release?
    - orbz 7y ago
      Just use it in your cloudbuild.yaml file: https://github.com/GoogleCloudPlatform/cloud-builders/tree/master/bazel https://github.com/GoogleCloudPlatform/cloud-builders/tree/m...
    - whs 7y ago
      https://blog.bazel.build/2018/10/05/remote-build-execution.html https://blog.bazel.build/2018/10/05/remote-build-execution.h...
Quekid5 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
The_rationalist 7y ago
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 ?
zulu_lefty 7y ago
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??
hsivonen 7y ago
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 7y ago
  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.
- berti 7y ago
  gn had the same problem when I looked at it in 2017. I was working with breakpad at the time (a Chromium subproject), and unfortunately they had only partially ported some platforms to gn, and I didn't feel like plumbing in 3 different build systems for the 3 different platforms. Long story short, gn was painful without the internal documentation Googlers presumably had.
haolez 7y ago
Is there something to gain from Basel on small projects?
- kevincox 7y ago
  Not as much. But quality cache invalidation and high level project descriptions are always nice.
adev_ 7y ago
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.
thundergolfer 7y ago
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
whoevercares 7y ago
Brazil blaze and bazel, someone should tell the story
mrath 7y ago
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 7y ago
  It doesn't require msys2 anymore, so you might want to try again.
mnarinsky 7y ago
Bazel 1.0 announcement on Google Open Source blog: https://opensource.googleblog.com/2019/10/bazel-reaches-10-milestone.html https://opensource.googleblog.com/2019/10/bazel-reaches-10-m... Provides more details on 1.0 changes and long term plans

Bazel Release 1.0

263 points by klodolph 7y ago

pnako 7y ago

Hundreds of developers around the Googleplex rejoice.

dickeytk 7y ago
Isn’t Bazel based off another tool they use internally?
- Spinfusor 7y ago
  Yes: the internal tool is Blaze
- klodolph 7y ago
  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.
  - ses1984 7y ago
    I want to try this with a monorepo codebase now but every time I try to get started I feel overwhelmed. I'm trying to sell my team on it, but none of us has experience with bazel. I'm trying to figure out how to do a small poc where we migrate one intermediate thing in the monorepo to bazel and try to prove out how it can take over everything.
    - klodolph 7y ago
      I have personally done this. - You are going to screw things up a couple times. The documentation for Bazel is not always clear, but you can usually find examples or explanations of complicated stuff on forums somewhere. - Start with a leaf dependency, something in your codebase that doesn’t depend on anything else. Then work your way up. Just write a WORKSPACE + BUILD.bazel in your root, and then put a BUILD.bazel in the directory for the dependency you are going to work on. - Look at examples like Tensor Flow, especially for how to handle third-party dependencies (although Tensor Flow is going to do it in a more complicated way). - Migrate your tests as you go. - Just run "bazel build //...:all" or "bazel test //...:all" from your project root as you go to make sure things don’t break. - Undoubtedly it will take a while to develop a good mental model of how Bazel works. For fun, try looking around in the output directories, or look at the sandboxes it creates.
      - ses1984 7y ago
        I appreciate your help and was curious if you could field one more specific question: What if I wanted to fork tensorflow and integrate my project into it, would I need the tensorflow fork as something like a git submodule in my main repo, or is there a way to tell bazel there's another repo somewhere else and where it fits into the graph?
  - evmar 7y ago
    Bazel is just the open source name of the internal Google build system, it is the same codebase.
    - klodolph 7y ago
      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

orangepanda 7y ago

Did they announce the deprecation date as well? https://killedbygoogle.com/ https://killedbygoogle.com/

javagram 7y ago
It’s OSS software not a SaaS. If people use it there will be no deprecation date. You can just fork and continue.
- dgellow 7y ago
  I’m sorry if that sounds harsh, but that’s at best a naive view. In practice you cannot just fork the codebase and continue maintaining it, that has a high cost that a lot of organization cannot afford. It’s technically true that you can fork the project but in practice forking something that big doesn’t really happen without a big player leading the fork (or some motivated people with enough time and money to dedicate to the fork, which is possible but unlikely).
  - javagram 7y ago
    Hence the “if people use it” qualifier. Companies relying on Bazel would step in and support it. We’ve seen this play out plenty of times before, e.g. Hudson to Jenkins or OpenOffice to LibreOffice, where a popular OSS product loses a corporate sponsor and continues.
    - dgellow 7y ago
      You’re ignoring all those times where that didn’t actually happen. It seems quite risky for an organization to rely on the idea “you can just fork and continue the development yourself in case of issues”. That’s not what happens in practice, taking over the development of something like bazel has a non-negligeable cost. Now for sure you can find some (cherry-picked IMHO) success stories but that’s the exception as far as I can tell.
- skybrian 7y ago

zegl 7y ago

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 7y ago
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 7y ago
  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.
  - afthonos 7y ago
    My experience is that I realized the value when I switched to a project that didn’t use it. Especially when I wanted to use other Google technologies like protos, or when I wanted to incrementally rebuild dependencies. Disclosure: I work at Google, with Blaze, but not on it, or on Bazel. All opinions mine.
  - klodolph 7y ago
    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.

mosselman 7y ago

What is it? What can I use this for?

klodolph 7y ago
It’s a build system. That might not be very exciting to you, but for large projects and multi-language projects it is usually much better than other build systems. It is designed to help give you fast distributed builds with high shared cache hit rates, reproducible builds, and a lot of tools to analyze dependencies. Personally, I like using it any time a project starts using multiple languages, protobufs, or generated sources.
paulddraper 7y ago
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.

amrox 7y ago

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?

Q6T46nT668w6i3m 7y ago
IIRC, transitive C++ libraries are coming sometime this year.
steeve 7y ago
It should be: --dynamic_mode=off

neves 7y ago

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

ihnorton 7y ago

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 7y ago
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)
- ahartmetz 7y ago
  Qt is moving to CMake for Qt6, they are already working on it. Qt6 release is planned in a year or so.
  - dgellow 7y ago
    I’m aware, that’s why I mentioned it.
- jchw 7y ago
  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.
  - berti 7y ago
    Last time I checked meson still doesn't have great Qt support e.g. it can't track rcc dependencies [0]. Funnily enough that issue is about rcc not making dependencies available to the build system, but I believe it actually started doing so somewhere down the track. I did a little work on it a couple of years back but regrettably never followed up [1]. [0] https://github.com/mesonbuild/meson/blob/27c01dff01832fa9d0c92602d0dc25b6ded9d2e9/mesonbuild/modules/qt5.py#L26 https://github.com/mesonbuild/meson/blob/27c01dff01832fa9d0c... [1] https://github.com/mesonbuild/meson/issues/97#issuecomment-329113396 https://github.com/mesonbuild/meson/issues/97#issuecomment-3...

habitue 7y ago

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.

klodolph 7y ago
> 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 the possibility that the third-party rules can mature. Its not too bad if you only need a couple sets of third-party rules but my experience is like yours-when a new Bazel release came out, you had to figure out when to upgrade based on your dependencies on third-party rules. If you had several of these, it made upgrading Bazel infeasible.
- jonhohle 7y ago
  Amazon’s build system handled this gracefully. Native build tool chains were always used, but wrapped in a relatively thin facade. As long as the buildtool could respond to a `release` target and put artifacts in a well known location it didn’t matter what the underlying implementation was. The biggest drawback that I could see was all dependencies and tool chain needed to be modeled, but once they were, incremental builds, dependency rebuilds, etc. all Just Worked™. Getting to that point requires a lot of upfront work, however, which can be hard to justify in smaller groups.

setheron 7y ago

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

miles_matthias 7y ago

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 7y ago
Does it work with VB6?
- m0zg 7y ago
  You jest, but you could totally write the rules for it to support VB6.
- etxm 7y ago
  Don’t look down your nose at VB, snobs.
- Gibbon1 7y ago
  Yeah we have a right to know
kovek 7y ago
That's cool, thanks Miles, I was looking at exactly this yesterday. I think I'll be able to finish figuring it out in the next few days when I have an hour or two.

rjsw 7y ago

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

kronin 7y ago

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

jingwen 7y ago
There are Bazel rules for Graal: https://github.com/andyscott/rules_graal https://github.com/andyscott/rules_graal

fuckyah 7y ago

one of the rabbit holes folks tend to get into is that bazel will magically solve their codebase problems. builds may be faster, but how about the IDE? most IDE's are not able to handel huge codebases well :/

throwaway13372 7y ago

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.

Unknoob 7y ago

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/rules-swift.html 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_swift https://github.com/bazelbuild/rules_apple https://github.com/bazelbuild/rules_apple

steeve 7y ago
We (Zenly) are, it works well!

aidenn0 7y ago

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?

KerrickStaley 7y ago
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).
wasyl 7y ago
> 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 7y ago
  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.

rad_gruchalski 7y ago

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

zapita 7y ago
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 7y ago
  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"

steeve 7y ago

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

random3 7y ago

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 7y ago
There's a hosted Bazel in an early access preview. Tensorflow uses it.
- random3 7y ago
  Thank you! Would love to try that. How to access pre-release?
  - orbz 7y ago
    Just use it in your cloudbuild.yaml file: https://github.com/GoogleCloudPlatform/cloud-builders/tree/master/bazel https://github.com/GoogleCloudPlatform/cloud-builders/tree/m...
  - whs 7y ago
    https://blog.bazel.build/2018/10/05/remote-build-execution.html https://blog.bazel.build/2018/10/05/remote-build-execution.h...

Quekid5 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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 7y ago

The_rationalist 7y ago

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 ?

zulu_lefty 7y ago

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

hsivonen 7y ago

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 7y ago
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.
berti 7y ago
gn had the same problem when I looked at it in 2017. I was working with breakpad at the time (a Chromium subproject), and unfortunately they had only partially ported some platforms to gn, and I didn't feel like plumbing in 3 different build systems for the 3 different platforms. Long story short, gn was painful without the internal documentation Googlers presumably had.

haolez 7y ago

Is there something to gain from Basel on small projects?

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

adev_ 7y ago

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.

thundergolfer 7y ago

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

whoevercares 7y ago

Brazil blaze and bazel, someone should tell the story

mrath 7y ago

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 7y ago
It doesn't require msys2 anymore, so you might want to try again.

mnarinsky 7y ago

Bazel 1.0 announcement on Google Open Source blog: https://opensource.googleblog.com/2019/10/bazel-reaches-10-milestone.html https://opensource.googleblog.com/2019/10/bazel-reaches-10-m... Provides more details on 1.0 changes and long term plans