|
1 | | -# Template for Bazel rules |
| 1 | +# Toolchain rules for bazel |
2 | 2 |
|
3 | | -Copy this template to create a Bazel ruleset. |
| 3 | +This repository contains rules for configuring toolchains. It is designed to be integrated with rulesets to allow a ruleset to specify what they _want_ an action to do, and have the configuration decide how to achieve that. For example, a ruleset author would specify `run_action(action_type=compile, variables = struct(header_files = [foo.h], source_files = [foo.cc], output = [foo.o]), inputs=[foo.cc, foo.h], outputs = [foo.o])`, and the configuration would turn that into the command-line `clang++ foo.cc foo.h -o foo.o`. |
4 | 4 |
|
5 | | -Features: |
| 5 | +# Getting Started |
6 | 6 |
|
7 | | -- follows the official style guide at https://bazel.build/rules/deploying |
8 | | -- allows for both WORKSPACE.bazel and bzlmod (MODULE.bazel) usage |
9 | | -- includes Bazel formatting as a pre-commit hook (using [buildifier]) |
10 | | -- includes stardoc API documentation generator |
11 | | -- includes typical toolchain setup |
12 | | -- CI configured with GitHub Actions |
13 | | -- release using GitHub Actions just by pushing a tag |
14 | | -- the release artifact doesn't need to be built by Bazel, but can still exclude files and stamp the version |
| 7 | +Add the following to your `MODULE.bazel` file: |
15 | 8 |
|
16 | | -# Bazel rules for toolchains |
| 9 | +```starlark |
| 10 | +bazel_dep(name = "rules_testing", version = "<version>") |
| 11 | +``` |
17 | 12 |
|
18 | | -## Installation |
| 13 | +## For ruleset authors |
19 | 14 |
|
20 | | -From the release you wish to use: |
21 | | -<https://github.com/matts1/rules_toolchains/releases> |
22 | | -copy the WORKSPACE snippet into your `WORKSPACE` file. |
| 15 | +Look at `examples/rules_lang`. You will first need to configure your toolchain to take in a `ToolchainConfig` parameter. |
23 | 16 |
|
24 | | -To use a commit rather than a release, you can point at any SHA of the repo. |
| 17 | +Once you've done that, you'll need to configure your rule to, instead of calling `ctx.actions.run`, call `run_action` (see [`examples/rules_lang/lang/defs.bzl`](examples/rules_lang/lang/defs.bzl)). |
25 | 18 |
|
26 | | -For example to use commit `abc123`: |
| 19 | +## For toolchain authors |
27 | 20 |
|
28 | | -1. Replace `url = "https://github.com/matts1/rules_toolchains/releases/download/v0.1.0/rules_toolchains-v0.1.0.tar.gz"` with a GitHub-provided source archive like `url = "https://github.com/matts1/rules_toolchains/archive/abc123.tar.gz"` |
29 | | -1. Replace `strip_prefix = "rules_toolchains-0.1.0"` with `strip_prefix = "rules_toolchains-abc123"` |
30 | | -1. Update the `sha256`. The easiest way to do this is to comment out the line, then Bazel will |
31 | | - print a message with the correct value. Note that GitHub source archives don't have a strong |
32 | | - guarantee on the sha256 stability, see |
33 | | - <https://github.blog/2023-02-21-update-on-the-future-stability-of-source-code-archives-and-hashes/> |
| 21 | +Either use the default toolchain configured by your ruleset author, or create a custom `toolchain_config` rule. |
| 22 | + |
| 23 | +# Testing |
| 24 | + |
| 25 | +`rules_toolchains` supports generating "input files". These files contain a full specification of generated actions, and can be used to validate that your toolchain configuration works as intended with golden tests. For an example of how this works, see `@rules_toolchain//tests`. |
| 26 | + |
| 27 | +# Contributing |
| 28 | + |
| 29 | +We appreciate your help! |
| 30 | + |
| 31 | +To contribute, please read the contribution guidelines: [CONTRIBUTING.md](https://github.com/matts1/rules_toolchains/blob/main/CONTRIBUTING.md). |
0 commit comments