HN user
jingwen
https://twitter.com/jin_
I work on the Bazel build system at Google.
The location is not hard-coded and can be configured with the --output_base flag.
Output directories are unique by the user and source project workspace directory. Output artifacts don't clobber, even though they are all in ~/.cache.
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.
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.
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...
More information on how to get access to Remote Build Execution for Bazel on GCP: https://docs.bazel.build/versions/master/remote-execution.ht...
(Disclaimer: I'm a engineer on the Bazel team)
(Disclaimer: Bazel engineer)
Bazel does ecosystem and language agnostic distributed builds with both GCP and self-hosted solutions.
Here's a demonstration of building the Angular project remotely: https://youtu.be/lDyIc2Abkwg?t=593
As one South-east Asian, thank you.
I've built an animated raytracer with an early version of this. http://raytracer.crypt.sg/
You may enjoy this article: https://ruudvanasseldonk.com/2018/09/03/build-system-insight...
Bazel integrates well with nixpkgs and npm with rules_nixpkgs [0] and rules_nodejs [1] respectively.
Tangentially related to package manager integration: Bazel can now build with CMake in-tree [2].
[0] https://github.com/bazelbuild/rules_nixpkgs/
Bazel supports persistent compilers with its worker protocol [0]. It's already supported for javac. It may be worthwhile to investigate how well zapcc can integrate with Bazel.
Bazel's buildfarm remote execution service is growing: https://github.com/bazelbuild/bazel-buildfarm
If you miss the clean UI and keyboard shortcuts of Google Reader, I highly recommend BazQux Reader.
The front end tech is also pretty interesting: it's built with Ur/Web. [2]
[1] http://bazqux.com [2] https://github.com/bazqux/bazqux-urweb
I'm unsure about the confidentiality of those systems, so I'm erring on the side of not expanding.
However by deriving from first principles, yes, there is no reason to re-query the transitive closure of unchanged targets' reverse deps, so caching can happen here.
I don't know if Google uses Jenkins
Yes, Google runs hosted Jenkins internally.
[Video] https://www.youtube.com/watch?v=rJXmGGu1kf8
[Slides] https://www.cloudbees.com/sites/default/files/2016-jenkins-w...
Is there a distributed execution backend like Forge at FB? If so, how similar is it to Forge?
This is one part of a _very_ big answer, but Bazel (internally Blaze) lets you do reverse dependency querying [0] with the query language, i.e. "Bazel, give me the list of targets that depend on this target that I've just modified"
$ bazel query 'rdeps(//foo/my:target, //...)'
Of course, this query in the monorepo will take a long time or not work, because the target universe of "//..." is far too large. This is where other systems come in.
[0] https://docs.bazel.build/versions/master/query.html#rdeps
Yep. Projects use Copybara to import/export OSS code. https://github.com/google/copybara
I found BazQux Reader (bazqux.com) and absolutely love it because it’s designed to mimic Google Reader :-)
If you're interested in learning more about gradual type systems, check out Jeremy Siek's work [0, 1]. He's one of the early researchers in this area.
[0] https://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typin... [1] https://github.com/samth/gradual-typing-bib
Switched to i3 a few weeks back and I absolutely love it. Switching between applications and workspaces is incredibly fast, and the _only_ time I need the mouse is for web browsing. It's amazing.
On my macOS work machine, Nix has replaced Homebrew. The ability to switch between generations of your system state [1] when a new install goes awry is underrated, IMO.