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.
> They've been breaking backwards compatibility constantly
I maintain a ruleset and have been on top of Bazel upgrades for a few months. My experience hasn't been so bad. There definitely are a lot of deprecations, and some code changes required, but it was pretty manageable IMHO.
With that said, I agree that some stacks are more first class citizens than others. But I feel this is more due to some stacks' departure from the C++ style of build management than an issue of Bazel changes. At our company, the Go org has had a pretty good experience with migrating from Buck to Bazel. For our web org, the main challenges have been that Bazel doesn't really lend itself well to dealing with codebases where inputs and outputs co-exist in the same filesystem tree (and this is incredibly common in the web world with things like babel transpiled files, yarn offline caches, lerna, etc) or where the ecosystem has a bad relationship with symlink handling (e.g. jest, flow, webpack, --preserve-symlinks, etc)
> 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.
Agree. I've been dealing with Python rules for Bazel at work and the default implementation of re-downloading everything with pip became a real pain real fast. Decided to generate the third party py_library with a separate tool instead and much happier for it. As an aside for those looking to start with Bazel, it's worth checking out the BazelBuild Slack -- https://slack.bazel.build/
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?
They're really excited about 1.0 for this reason, they're tired of breaking other people's builds too. The goal is to limit that with the 1.0 release, so expect this to get a lot better.
They’re underinvesting in their Python story in my opinion.
To my knowledge rules_python still doesn’t support pip3 installs, and from browsing Github, Twitter, and the Bazel Slack it seems everyone is reimplementing their own package management integration because the default is so undercooked.
Right now rules_pygen is the best open source option, but it isn’t fully featured and was broken by Bazel 0.28.
About the container stuff specifically, I think the different solution provided here versus off-the-shelf Docker is not merely to be compatible with Bazel. Rather it looks like, from having used it modestly, an intentionally different way of thinking about container builds, aiming toward different performance characteristics that scale etc.
I can't think of any reason you couldn't call the docker tools in a genrule() though, if you prefer.
> but the ecosystem around Bazel is quite bad at the moment
I've noticed this as well. I'd love to use Bazel for our Python 3 project, but as far as I can tell, the advertised Python 3 support doesn't actually work. There are several issues filed for this, but apparently no progress since 2018. Some people reported workarounds, but none that I could reproduce.
I believe the core is solid, but language support feels alpha at best.
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!
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
Happy to answer any questions, public or private (email / website in bio).
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.
I hope that this 1.0 status will prompt the Qt people to take a closer look at Bazel, but that's probably strongly conditioned on the quality of Windows support. Qt Co. have indicated that CMake is the most likely replacement for qmake in Qt 6, which would be a lateral change at best.
Is anyone using Bazel to ship cross-platform GUI applications?
> I hope that this 1.0 status will prompt the Qt people to take a closer look at Bazel
By the sake of God no.
The last thing I need to compile Qt is a gigantic framework requiring the JVM.
Plus the fact Bazel has so many side effect that that even quantum physics experiments looks more reproducible: Just try to compile tensorflow and enjoy the fun.
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.)
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.
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.
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?
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
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.
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.
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).
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
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?
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?
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.
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 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?
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.
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.
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.
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.
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 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|6 years ago|reply
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.
[+] [-] lhorie|6 years ago|reply
I maintain a ruleset and have been on top of Bazel upgrades for a few months. My experience hasn't been so bad. There definitely are a lot of deprecations, and some code changes required, but it was pretty manageable IMHO.
With that said, I agree that some stacks are more first class citizens than others. But I feel this is more due to some stacks' departure from the C++ style of build management than an issue of Bazel changes. At our company, the Go org has had a pretty good experience with migrating from Buck to Bazel. For our web org, the main challenges have been that Bazel doesn't really lend itself well to dealing with codebases where inputs and outputs co-exist in the same filesystem tree (and this is incredibly common in the web world with things like babel transpiled files, yarn offline caches, lerna, etc) or where the ecosystem has a bad relationship with symlink handling (e.g. jest, flow, webpack, --preserve-symlinks, etc)
[+] [-] klodolph|6 years ago|reply
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.
[+] [-] c4urself|6 years ago|reply
[+] [-] mrighele|6 years ago|reply
[+] [-] miles_matthias|6 years ago|reply
[+] [-] thundergolfer|6 years ago|reply
To my knowledge rules_python still doesn’t support pip3 installs, and from browsing Github, Twitter, and the Bazel Slack it seems everyone is reimplementing their own package management integration because the default is so undercooked.
Right now rules_pygen is the best open source option, but it isn’t fully featured and was broken by Bazel 0.28.
[+] [-] kylecordes|6 years ago|reply
I can't think of any reason you couldn't call the docker tools in a genrule() though, if you prefer.
[+] [-] weberc2|6 years ago|reply
I've noticed this as well. I'd love to use Bazel for our Python 3 project, but as far as I can tell, the advertised Python 3 support doesn't actually work. There are several issues filed for this, but apparently no progress since 2018. Some people reported workarounds, but none that I could reproduce.
I believe the core is solid, but language support feels alpha at best.
[+] [-] zegl|6 years ago|reply
A huge congratulations to the Bazel team for shipping 1.0!
[+] [-] miles_matthias|6 years ago|reply
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
Happy to answer any questions, public or private (email / website in bio).
[+] [-] kovek|6 years ago|reply
[+] [-] etxm|6 years ago|reply
[+] [-] ihnorton|6 years ago|reply
Is anyone using Bazel to ship cross-platform GUI applications?
[+] [-] adev_|6 years ago|reply
By the sake of God no.
The last thing I need to compile Qt is a gigantic framework requiring the JVM. Plus the fact Bazel has so many side effect that that even quantum physics experiments looks more reproducible: Just try to compile tensorflow and enjoy the fun.
Stick to CMake, thanks.
[+] [-] dgellow|6 years ago|reply
(Also, cmake has become the de facto solution for open source libraries, not sure why they would select something else)
[+] [-] hsivonen|6 years ago|reply
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|6 years ago|reply
[+] [-] berti|6 years ago|reply
[+] [-] Quekid5|6 years ago|reply
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|6 years ago|reply
[+] [-] setheron|6 years ago|reply
[+] [-] beisner|6 years ago|reply
[+] [-] aidenn0|6 years ago|reply
[+] [-] KerrickStaley|6 years ago|reply
[+] [-] wasyl|6 years ago|reply
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
[+] [-] zulu_lefty|6 years ago|reply
the binary ships it own JRE and starts instantly (uses a server), why is java an issue exactly??
[+] [-] steeve|6 years ago|reply
[+] [-] wasyl|6 years ago|reply
[+] [-] Unknoob|6 years ago|reply
Has anyone gotten a Swift + Objective-C project running on Bazel or should I stay with Facebook's Buck?
[1]: https://github.com/bazelbuild/rules_apple/blob/master/doc/ru...
Edit: Found the correct links for the Swift/Apple support docs.
https://github.com/bazelbuild/rules_swift
https://github.com/bazelbuild/rules_apple
[+] [-] steeve|6 years ago|reply
[+] [-] neves|6 years ago|reply
I don't like the tooks, but would it be worth the trouble to change to Bazel?
[+] [-] klodolph|6 years ago|reply
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.
[+] [-] random3|6 years ago|reply
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|6 years ago|reply
[+] [-] amrox|6 years ago|reply
[+] [-] steeve|6 years ago|reply
[+] [-] Q6T46nT668w6i3m|6 years ago|reply
[+] [-] adev_|6 years ago|reply
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), Nix (https://nixos.org/nix/), GUIX (http://guix.gnu.org/) gives 95% of the advantages of Bazel without the pains of it.
[+] [-] cromwellian|6 years ago|reply
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.
[+] [-] thundergolfer|6 years ago|reply
I aim to follow best practices and mark out any undocumented gotchas.
https://github.com/thundergolfer/the-one-true-bazel-monorepo
[+] [-] mosselman|6 years ago|reply
[+] [-] paulddraper|6 years ago|reply
* 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.
[+] [-] klodolph|6 years ago|reply
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.
[+] [-] mrath|6 years ago|reply
[+] [-] meisterT|6 years ago|reply
[+] [-] kronin|6 years ago|reply
[+] [-] jingwen|6 years ago|reply
[+] [-] rad_gruchalski|6 years ago|reply
[+] [-] zapita|6 years ago|reply
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.