Keeping your deps tidy

My coworker Carmi just published a blog post on the Bazel blog about how Java tracks dependencies. Bazel has some nice facilities built in to let you know when you need to add dependencies: ERROR: /home/kchodorow/test/a/BUILD:24:1: Building libA.jar (1 source file) failed: Worker process sent response with exit code: 1. error: [strict] Using typeContinue reading “Keeping your deps tidy”

How to Skylark – the class

I’ve heard a lot of users say they want a more comprehensive introduction to writing build extensions for Bazel (aka, Skylark). One of my friends has been working on Google Classroom and they just launched, so I created a build extensions crash course. I haven’t written much content yet (and I don’t understand exactly howContinue reading “How to Skylark – the class”

Low-fat Skylark rules – saving memory with depsets

In my previous post on aspects, I used a Bazel aspect to generate a simple Makefile for a project. In particular, I passed a list of .o files up the tree like so: dotos = [ + “.o”] for dep in ctx.rule.attr.deps: # Create a new array by concatenating this .o with all previous .o’s.Continue reading “Low-fat Skylark rules – saving memory with depsets”

Aspects: the fan-fic of build rules

Aspects are a feature of Bazel that are basically like fan-fic, if build rules were stories: aspects let you add features that require intimate knowledge of the build graph, but that that the rule maintainer would never want to add. For example, let’s say we want to be able to generate Makefiles from a BazelContinue reading “Aspects: the fan-fic of build rules”

The Mixed-Up Directories of Mrs. Bazel E. Frankweiler

Bazel has several directory trees that it uses during a build. Sources The most obvious directory is the source tree where your code lives and where you run your builds. This is, by default, what Bazel uses for source files. However, you can combine several source trees by using the –package_path option. This basically overlaysContinue reading “The Mixed-Up Directories of Mrs. Bazel E. Frankweiler”

Custom, locally-sourced output filenames

Skylark lets you use templates in your output file name, e.g., this would create a file called target.timestamp: touch = rule( outputs = {“date_and_time”: “%{name}.timestamp”}, implementation = _impl, ) So if you had touch(name = “foo”) in a BUILD file and built :foo, you’d get foo.timestamp. I’d always used %{name}, but I found out theContinue reading “Custom, locally-sourced output filenames”

Using environment variables in Skylark repository rules

If you’ve every used the AppEngine rules, you know the pain that is wait for all 200 stupid megabytes of API to be downloaded. The pain is doubled because I already have a copy of these rules on my workstation. To use the local rules, all I have to do is override the @com_google_appengine_java repositoryContinue reading “Using environment variables in Skylark repository rules”

Communicating between Bazel rules: how to use Skylark providers

Rules in Bazel often need information from their dependencies. My previous post touched on a special case of this: figuring out what a dependency’s runfiles are. However, Skylark is actually capable of passing arbitrary information between rules using a system known as providers. Suppose we have a rule, analyze_flavors, that figures out what all ofContinue reading “Communicating between Bazel rules: how to use Skylark providers”