7 ms·
In practice, this isn't generally noticeable. Bazel is pretty damn fast, and even ships with its own JVM so installing it is pretty much painless. I agree on t
by q3k 6y ago
In practice, this isn't generally noticeable. Bazel is pretty damn fast, and even ships with its own JVM so installing it is pretty much painless.
I agree on the bootstrapping issues resulting from that, though.
- an_d_rew 6y agoUnfortunately, for us, Java “out of memory” errors are routine, and for even moderately-sized monorepos the RAM requirements can get insane.
- dleslie 6y agoPrecisely this. Advocating for Java as a general purpose tool language sort of overlooks the incredibly broad and prevasive installbase of machines more than ten years old, as well as the rapidly growing installbase of ARM SOC machines. For many, a tool eating up a gigabyte or more of memory is certainly not acceptable.
- gerash 6y agoI'm lost. Can't people build their binaries on a powerful machine instead of an ARM tablet?
- dleslie 6y agoNot everyone has a powerful machine to do so with; many folks are still using computers that shipped with WinXP, or even Vista or 98/Me. It's a huge world outside of California. Personally, my primary home/non-work machines are an RPi4 and a Pinebook Pro.
- orf 6y agoSo Google should ship a potentially inferior tool, slower, because some people run on inappropriate or highly outdated hardware? Hmm.
- brmgb 6y agoNo, Bazel just fails to satisfy the very real need of building on less powerful machines because of its technological choice, a need served by other tools competing with it, and therefore is not really a truly general, one size fit all, solution. The fact that you personally deem the needs of others illegitimate doesn't preclude them from actually existing.
- dleslie 6y agoThe topic is whether FOSS developers should use Bazel, not whether Bazel is good for Google. For many it is Bazel that is inferior due to development environment constraints. And "outdated" is a questionable term: if it satisfies their needs, why upgrade? Maybe Google should build better tools.
- oblio 6y agoI think you're part of a minority, though. You're talking about computers from 20, 20+ years ago and about Raspberry Pi. It's a personal choice. You can get a good second hand desktop from 2012-2015 for the price of your Raspberry Pi.
- dleslie 6y agoTravel to Africa, India and South East Asia some time. The world is a big place outside of California, and the hardware available to many is not what you'll find at a cafe in San Francisco.
- gerash 6y agoI've lived in other less developed countries and it's not like a raspberry Pi is the most people can afford there. Have you lived in the places you've listed?
- dleslie 6y agoThe RPi is an example of a growing SOC device market, but I did mention as well the enormous install base of older and under-powered devices in general. I have family in Colombia.
- oblio 6y agoI don't live in California (nor the US), I've only visited twice or so. I'm from a place similar to those you're describing. Few people would get enthusiast gear like Raspberry Pi. What they would get, instead, would be an old x86 PC with pirated Windows. A crummy knock off Chinese laptop or locally assembled PC (so not from the big OEMs).
- dleslie 6y agoIt seems we agree, then? Those devices you mention would be in the category of older, lower-power machines that I mentioned.
- jsolson 6y agoI'm curious what you consider "insane" to be -- and I mean this genuinely. Google has what I think most would consider to be a large monorepo, but also provides developer desktops with ample RAM. I've noticed blaze's startup time, but never really thought about its memory consumption. Where are you running into limits?
- smiths1999 6y agoDoesn't blaze build remotely via citc? I thought files were loaded locally for editing but built remotely.
- jsolson 6y agoBlaze itself runs locally, reading BUILD files from citc. The build actions mostly execute remotely.
- an_d_rew 6y ago10,000+ artifacts on a 20 core Intel box with 64 Gb RAM. We have some peculiarities of our Bazel setup that are not common, yet are (supposed to be) fully supported. Building can take hours.
- laurentlb 6y agoAre you using remote execution with Bazel? If you have hour long builds, it's often worth investing in remote execution (just remote caching can help too).
- millstone 6y agoThe effect is that open source projects avoid Bazel. I'd rather fight with CMake than take a Java dependency in a C++ codebase. It's a pity, feels like a real missed opportunity.
- klodolph 6y agoI think open-source projects avoid Bazel not because of the Java issue. You can install it pretty easily and never realize that it's written in Java. By analogy, I'd say that if Make is a hammer, Bazel is a CNC machine. Most DIYers are going to have hammers, and everyone understands how to use them, but CNC machines are becoming cheaper and more common.
- millstone 6y agoThe official .deb is 156MB compressed, which is prohibitive for all but the largest OSS projects. I assume much of that is the bundled JRE, but that only illustrates the point about Java. Most tellingly, Google has gone through two major build system migrations (Android and Chrome), and neither project chose to migrate to Bazel/Blaze. If Google won't eat their own dogfood, it doesn't inspire much confidence.
- q3k 6y ago> If Google won't eat their own dogfood, it doesn't inspire much confidence. Chromium's gn started being prototyped in 2013 [1]. Android's soong started being developed in June 2015 [2]. Bazel's first open source release was in September 2015 [3]. In addition, you surely can't be serious about Google not 'dogfooding Blaze' - it's a critical build system internally at Google. And new external projects (like gVisor) are also now built using Bazel. [1] https://chromium.googlesource.com/chromium/src/tools/gn/+/3bd230b9a2b5c011dad077d810642b5c539fcb74 https://chromium.googlesource.com/chromium/src/tools/gn/+/3b... [2] https://android.googlesource.com/platform/build/soong/+/e441b9df9a68595d0dd7b8ed184aecb27c86054b https://android.googlesource.com/platform/build/soong/+/e441... [3] https://github.com/bazelbuild/bazel/releases/tag/0.1.0 https://github.com/bazelbuild/bazel/releases/tag/0.1.0
- mehrdadn 6y ago> I agree on the bootstrapping issues resulting from that, though. What are these "issues"?
- q3k 6y agoTo build Bazel from source in an environment where you don't want to use any Internet binaries, you need a Java built from source. Needing a Java is painful. You also need a Bazel to build Bazel. And Bazel's build system itself IIRC wants to download stuff from the Internet on build - which can be pre-fetched, but distro maintainers still don't like having to deal with taht.
- mehrdadn 6y agoEdit: never mind, I think I was confused what the comment was saying.
- SubjectToChange 6y agoLook at what Nix or Guix would have to do to build a project using Bazel vs a project using CMake.
- vips7L 6y agoThis is nonsense building OpenJDK from source should be as easy as: bash configure && make images
- Joky 6y agoThe speed and responsiveness is there, but the price is a tricky management of background daemon and aggressive memory prefetch and caching which may be a bit heavy on memory resources (which is then less available to the compiler processes). This works out well when you run the Bazel daemon locally and distribute the work to a remote build farm, but less when you're building a project like LLVM on your laptop.