More here: https://docs.bazel.build/versions/master/remote-execution.ht...

Output directories are unique by the user and source project workspace directory. Output artifacts don't clobber, even though they are all in ~/.cache.

Other reasons to avoid the home directory:

1. It might be NFS mounted.

2. Space might be an issue and more difficult to plan for if build outputs are going there.

The location is not hard-coded and can be configured with the --output_base flag.

> The net result is a Bazel (and Blaze) that are less burdened by the baggage of legacy, but the cost is a faster treadmill to keep pace with changes.

(I work on Bazel.)

This is accurate. A few of the biggest breaking change themes are:

1) Converting functionality linked within the Bazel binary into the extensibility mechanism implemented in Starlark. An example includes converting the native Java, C++, Android, Python, Protobuf, Obj-C and packaging rules into rules_java, rules_cc, etc. Many languages now are already implemented exclusively in Starlark. See rules_scala, rules_rust, rules_go and rules_haskell.

2) Starlark and Build API cleanups that accumulated over organic growth and development within Google for the past decade.

3) New build system features to support seamless integration with other build systems and package managers.

There are many layers of caching within Bazel (remote/local, inmemory/disk), but the central functional incremental engine is called Skyframe [1]. Almost every computation within Bazel that can be incrementally executed is managed in this engine.

[1]: https://bazel.build/designs/skyframe.html

That's right. However, there are distinct implications on how this dependency graph is constructed, analyzed, and evaluated. "Build Systems à la Carte" (Mokhov, Mitchell, Peyton Jones) [1] goes deeper into formalizing these differences.

[1] https://www.microsoft.com/en-us/research/uploads/prod/2018/0...

Yes. 1.0 indicates the beginning of semantic versioning, which was not in place during the alpha and beta phases.

Exactly this. It's not fair to complain about breaking changes in a product pre 1.0.

Also, unless they had wildly different versioning pre 1.0, they could have just said "we are releasing 1.0". semver already states that 0.y.z should not be considered a stable API [1].

[1] https://github.com/semver/semver/blob/master/semver.md

The Bazel team published official rules for managing transitive dependencies from Maven: https://github.com/bazelbuild/rules_jvm_external

There are also community created solutions like https://github.com/johnynek/bazel-deps, and https://github.com/square/bazel_maven_repository.

Disclosure: I maintain rules_jvm_external.

There are Bazel rules for Graal: https://github.com/andyscott/rules_graal

Check out Bazel's remote execution feature and Google RBE (remote build execution) [1]. Bazel itself is language agnostic (language support comes in the form of rules).

(disclaimer: I'm an engineer on the Bazel team)

[1] https://docs.bazel.build/versions/master/remote-execution.ht...

There's also an opensource goma client + server which proxies to RBE (or potentially other bazel remote execution API implementations). Which is great if you can't or don't want to use the bazel client, but can use a compiler wrapper.

https://chromium.googlesource.com/infra/goma/client/ https://chromium.googlesource.com/infra/goma/server/