Four alternative debugging techniques

I’ve recently been working on a side project that uses WebGL and a physics engine that was transpiled from C++ into JavaScript so… printing variable to the console and using the debugger just weren’t cutting it. I started thinking about the other ways I debug things: Ship of Theseus debugging: the ship of Theseus isContinue reading “Four alternative debugging techniques”

Compilation à la mode

Bazel lets you set up various “modes” of compilation. There are several built-in (fast, optimized, debug) and you can define your own. The built in ones are: Fast: build your program as quickly as possible. This is generally best for development (when you want a tight compile/edit loop) and is the default, when you don’tContinue reading “Compilation à la mode”

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”

Collecting transitive runfiles with skylark

Bazel has a concept it calls runfiles for files that a binary uses during execution. For example, a binary might need to read in a CSV, an ssh key, or a .json file. These files are generally specified separately from your sources for a couple of reasons: Bazel can understand that it is a runtime,Continue reading “Collecting transitive runfiles with skylark”

Startup idea #6ec4e42a-28cc-4425-9ebc-61ac8e224580: Adventurer’s gear for geeky hikers

I’m going to start “calling” my startup ideas in the same way Andy Dwyer calls band names. So, first up: it’s like REI for D&D players. We’d sell a “basic adventurer’s kit” that came with iron rations, wineskin, torches, 50 feet of rope, etc. Then you could get “class specialization” kits, for example: Rogue: containsContinue reading “Startup idea #6ec4e42a-28cc-4425-9ebc-61ac8e224580: Adventurer’s gear for geeky hikers”

Using a generated header file as a dependecy

Someone asked me today about how to use a generated header as a C++ dependency in Bazel, so I figured I’d write up a quick example. Create a BUILD file with a genrule that generates the header and a cc_library that wraps it, say, foo/BUILD: genrule( name = “header-gen”, outs = [“my-header.h”], # This commandContinue reading “Using a generated header file as a dependecy”