bazel

The list captures projects written in the Java language, not for Java ecosystem. See why it is critical here - https://github.com/bazelbuild/bazel/wiki/Bazel-Users

All the official Bazel .deb files since Bazel 1.0 have been around 42MB See https://github.com/bazelbuild/bazel/releases/tag/3.7.0 for the latest release Most open-sourced Google projects use Bazel now. Of course, projects like Android and Chrome have been around for a long time and have invested in their build systems, so any change will take years. (disclaimer: I've worked on Bazel)

> 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/+/3b... [2] https://android.googlesource.com/platform/build/soong/+/e441... [3] https://github.com/bazelbuild/bazel/releases/tag/0.1.0

Bazel has plenty of its own correctness problems. Like https://github.com/bazelbuild/bazel/issues/3360 . It used to be the case that file hashing wasn't coordinated well with a concurrently edited file, so changing source while building corrupts your cache.

I mean sure, you always need to start with a binary somewhere, but to put this into perspective... the binaries needed to bootstrap all the software on the distro I run on my laptop weigh in at about 60 MiB[0]. An x86_64 build of Bazel alone weighs in at about 27 MiB[1]. As someone who cares about source bootstrappability, that feels like sliding backwards. I suppose you may be able to find a chain of older versions of Bazel starting with one that doesn't require Bazel itself to build, like the Guix devs did for Rust[2]. [0] https://guix.gnu.org/blog/2020/guix-further-reduces-bootstra... [1] https://github.com/bazelbuild/bazel/releases/tag/3.5.0 [2] https://guix.gnu.org/blog/2018/bootstrapping-rust/

Short version: file paths are an OS-specific construct, and not all OSes have paths that can be round-tripped through Unicode. The first bad option is to say "paths are bytes", which is true on traditional POSIX platforms. Then you run your code on macOS and discover it's processing your bytes as UTF-8 and applying Unicode normalization. After fixing that you try porting to Windows and get to learn about `wchar_t`. The other bad option is to say "paths are (Unicode) strings", which works fine on Windows and macOS. It works 90% of the time on POSIX, but you'll eventually find users with non-UTF8 file paths and then you're in trouble. My first hand experience with this going wrong is GHC, which started off with raw bytes, then moved to strings using a bad conversion function, then they tried to work around the issue by placing non-UTF8 byte

yes that's indeed a problem that needs to be dealt with. That said, technically the getsum client doesn't download the file; it only fetches "$url.sha256" if present or a "SHA256SUMS" in the same directory and compares that with the one stored in the transparency log. It follows a common pattern on release sites (such as major projects on github). In other words getsum only ensures that the checksum file itself is immutable, and the checksum file then is used to ensure that bigger file also hasn't changed. The reason for that lies in the fact that getsum has a server side component (hosted on getsum.pub) that serves the Go modules fetched by the Go sumdb. Thus, the correct instructions are: $ (echo -n $(getsum https://github.com/bazelbuild/bazel/releases/download/3.4.1/bazel-3.4.1-installer-…); echo " bazel-3.4.1-install

Some time ago I made a fun hack where I abuse the Go transparency log to store immutable url->fingerprint mappings of arbitrary urls: https://github.com/mkmik/getsum Example: $ getsum https://github.com/bazelbuild/bazel/releases/download/3.4.1/bazel-3.4.1-installer-… 9808adad931ac652e8ff5022a74507c532250c2091d21d6aebc7064573669cc5 now, if somebody ever replaces that file on github, getsum will fail with an error. (I was too lazy to make getsum actually download the file if the checksum matches, but that should be trivial; for now just do "getsum $url && wget $url"). This works by creating synthetic Go modules that embed "facts" about URLs inside generated Go code, which gets then downloaded by getsum and parsed using the stdlib "go/parser" package. Since all Go modules are recorded in the Go "sumdb" public transpare

Bazel is definitely buggy. One of the silliest ones is this one (and as far as this one goes, I do not understand how this issue exists when Blaze has been used in Google for such a long itme): https://github.com/bazelbuild/bazel/issues/9419 One of the more fundamental bugs is this one: https://github.com/bazelbuild/bazel/issues/4558 I've even had to clean --expunge and clear my disk cache to fix some build errors before. Bazel paints a rosy picture of the world, but the real world is messy, and Bazel builds aren't as reproducible as it makes you want to think. (Which BTW is one thing that's had me asking so many questions about Nix.) At least the fact that it does not track changes outside the workspace means you can update your system compilers (or Python, or whatever) and end up with build outputs that will not be reproduced from scrat

I wish Bazel was more explicit about things leaking in from outside the workspace, but you can always vendor the toolchain to be more hermetic. For example see https://github.com/grailbio/bazel-toolchain which sets up LLVM and Clang for you. https://github.com/bazelbuild/bazel/issues/4558

https://github.com/bazelbuild/bazel/commit/ed7ced0018dc5c5eb... <-- would be better with DNSSEC though

Bazel uses a subset of Python for describing build rules Bazel's configuration language is called Starlark[0] (used to be Skylark). It's not a strict subset of Python. It has implementations in Java[1] and Go[2]. I haven't had a chance to use it yet, but it seems very useful as a general-purpose scripting language, especially for embedding into tools. [0] https://docs.bazel.build/versions/master/skylark/language.ht... [1] https://github.com/bazelbuild/bazel/tree/master/src/main/jav... [2] https://github.com/google/starlark-go