diff --git a/site/docs/cc-toolchain-config-reference.md b/site/docs/cc-toolchain-config-reference.md index fddfeac1c204d0..ff1e54cc40a50c 100644 --- a/site/docs/cc-toolchain-config-reference.md +++ b/site/docs/cc-toolchain-config-reference.md @@ -361,12 +361,14 @@ and encode some semantics into the name. -## Action config +## Using action_config -A `action_config` is a Starlark struct that describes a Bazel action -by specifying the tool (binary) to invoke during the action and sets of flags, -defined by features, that apply constraints to the action's execution. The -`action_config()` constructor has the following parameters: +The `action_config` is a Starlark struct that describes a Bazel +action by specifying the tool (binary) to invoke during the action and sets of +flags, defined by features. These flags apply constraints to the action's +execution. + +The `action_config()` constructor has the following parameters: @@ -425,7 +427,7 @@ within the same toolchain. This prevents ambiguity in tool paths and enforces the intention behind `action_config` - that an action's properties are clearly described in a single place in the toolchain. -### `tool` +### Using tool constructor An`action_config` can specify a set of tools via its `tools` parameter. The `tool()` constructor takes in the following parameters: @@ -449,7 +451,7 @@ The `tool()` constructor takes in the following parameters: - @@ -662,12 +664,12 @@ variable or its field using the `expand_if_available`, `expand_if_not_available` the build command only when a currently iterated library has an `is_whole_archive` field. -## `CcToolchainConfigInfo` reference +## CcToolchainConfigInfo reference This section provides a reference of build variables, features, and other information required to successfully configure C++ rules. -### `CcToolchainConfigInfo` build variables +### CcToolchainConfigInfo build variables The following is a reference of `CcToolchainConfigInfo` build variables. diff --git a/site/docs/generate-workspace.md b/site/docs/generate-workspace.md index c88f34e4c9e720..a9ff603609e7b6 100644 --- a/site/docs/generate-workspace.md +++ b/site/docs/generate-workspace.md @@ -23,7 +23,7 @@ which includes: * the `generated_java_libraries` macro that will contain a library for each maven_jar. -## Install `generate_workspace` +## Install generate_workspace Bazel's binary installer does not include `generate_workspace`. To be able to use this tool: diff --git a/site/docs/remote-execution-ci.md b/site/docs/remote-execution-ci.md index 42221a371237d2..ff2daa3aca52ec 100644 --- a/site/docs/remote-execution-ci.md +++ b/site/docs/remote-execution-ci.md @@ -77,7 +77,7 @@ If your build or tests fail, it's likely due to the following: [Adapting Bazel Rules for Remote Execution](remote-execution-rules.html) for details about compatibility with remote execution. -## Using a custom container in the `rbe_ubuntu1604` CI config +## Using a custom container in the rbe_ubuntu1604 CI config The `rbe-ubuntu16-04` container is publicly available at the following URL: @@ -92,7 +92,7 @@ Before you begin, make sure you have installed `gcloud`, `docker`, and `git`. If you are building the container from source, you must also install the latest version of Bazel. -### Pulling the `rbe-ubuntu16-04` from Container Registry +### Pulling the rbe-ubuntu16-04 from Container Registry To pull the Pull the `rbe-ubuntu16-04` container from Container Registry, run the following command: @@ -104,7 +104,7 @@ gcloud docker -- pull gcr.io/cloud-marketplace/google/rbe-ubuntu16-04@sha256:` with the SHA256 checksum value for [the latest container](https://console.cloud.google.com/gcr/images/cloud-marketplace/GLOBAL/google/rbe-ubuntu16-04). -### Building the `rbe-ubuntu16-04` container from source +### Building the rbe-ubuntu16-04 container from source To build the `rbe-ubuntu16-04` container from source, do the following: diff --git a/site/docs/remote-execution-rules.md b/site/docs/remote-execution-rules.md index a382f78095dce5..d48c33a45a5cc7 100644 --- a/site/docs/remote-execution-rules.md +++ b/site/docs/remote-execution-rules.md @@ -108,7 +108,7 @@ one of the following: toolchain container) if it's stable enough and use toolchain rules to run it in your build. -## Managing `configure`-style WORKSPACE rules +## Managing configure-style WORKSPACE rules Bazel's `WORKSPACE` rules can be used for probing the host platform for tools and libraries required by the build, which, for local builds, is also Bazel's diff --git a/site/docs/skylark/config.md b/site/docs/skylark/config.md index bb6b90870801d3..0b2b84f3ac4926 100644 --- a/site/docs/skylark/config.md +++ b/site/docs/skylark/config.md @@ -79,7 +79,7 @@ writer have some debug mode that you'd like to turn on inside test rules, you don't want to give users the ability to indiscriminately turn on that feature inside other non-test rules. -#### Using `ctx.build_setting_value` +#### Using ctx.build_setting_value Like all rules, build setting rules have [implementation functions](rules.html#implementation-function). The basic Starlark-type value of the build settings can be accessed via the @@ -371,7 +371,7 @@ label_flag( TODO(bazel-team): Expand supported build setting types. -### Build settings and `select()` +### Build settings and select() [End to end example](https://github.com/bazelbuild/examples/tree/master/rules/starlark_configurations/select_on_build_setting) diff --git a/site/docs/skylark/performance.md b/site/docs/skylark/performance.md index 1ddbfd384ac5a9..890c4b2ac15dcc 100644 --- a/site/docs/skylark/performance.md +++ b/site/docs/skylark/performance.md @@ -119,7 +119,7 @@ This can sometimes be reduced using a list comprehension: x = depset(transitive = [i.deps for i in inputs]) ``` -## Use `ctx.actions.args()` for command lines +## Use ctx.actions.args() for command lines When building command lines you should use [ctx.actions.args()](lib/Args.html). This defers expansion of any depsets to the execution phase. diff --git a/site/docs/skylark/tutorial-custom-verbs.md b/site/docs/skylark/tutorial-custom-verbs.md index 0cc487499758a6..c1db307f3e9e73 100644 --- a/site/docs/skylark/tutorial-custom-verbs.md +++ b/site/docs/skylark/tutorial-custom-verbs.md @@ -12,7 +12,7 @@ push packages to a repository, publish documentation for end-users, or deploy an application with Kubernetes. But Bazel doesn't have a `publish` or `deploy` command – where do these actions fit in? -## The versatility of `bazel run` +## The bazel run command Bazel's focus on hermeticity, reproducibility, and incrementality means the `build` and `test` commands aren't helpful for the above tasks. These actions @@ -24,7 +24,7 @@ side effects. Bazel users are accustomed to rules that create executables, and rule authors can follow a common set of patterns to extend this to "custom verbs". -### In the wild: `rules_k8s` +### In the wild: rules_k8s For example, consider [`rules_k8s`](https://github.com/bazelbuild/rules_k8s), the Kubernetes rules for Bazel. Suppose you have the following target: @@ -46,7 +46,7 @@ scripts to perform those actions, and when executed with `bazel run staging.apply`, these behave like our own `bazel k8s-apply` or `bazel k8s-delete` commands. -### Another example: `ts_api_guardian_test` +### Another example: ts_api_guardian_test This pattern can also be seen in the Angular project. The [`ts_api_guardian_test` macro](https://github.com/angular/angular/blob/16ac611a8410e6bcef8ffc779f488ca4fa102155/tools/ts-api-guardian/index.bzl#L22) diff --git a/site/docs/windows.md b/site/docs/windows.md index f900895d426ee5..5ad86e0410bb0f 100644 --- a/site/docs/windows.md +++ b/site/docs/windows.md @@ -72,7 +72,8 @@ details. ### Using Bazel without Bash (MSYS2) -#### `bazel build` without Bash + +#### Using bazel build without Bash Bazel versions before 1.0 used to require Bash to build some rules. @@ -91,7 +92,7 @@ in the When built on Windows, **these rules do not require Bash**. -#### `bazel test` without Bash +#### Using bazel test without Bash Bazel versions before 1.0 used to require Bash to `bazel test` anything. @@ -101,7 +102,7 @@ Starting with Bazel 1.0, you can test any rule without Bash, except when: - the test rule itself requires Bash (because its executable is a shell script) -#### `bazel run` without Bash +#### Using bazel run without Bash Bazel versions before 1.0 used to require Bash to `bazel run` anything. @@ -111,7 +112,7 @@ Starting with Bazel 1.0, you can run any rule without Bash, except when: - the test rule itself requires Bash (because its executable is a shell script) -#### `sh_binary` and `sh_*` rules, and `ctx.actions.run_shell()` without Bash +#### Using sh_binary and sh_* rules, and ctx.actions.run_shell() without Bash You need Bash to build and test `sh_*` rules, and to build and test Starlark rules that use `ctx.actions.run_shell()` and `ctx.resolve_command()`. This
with_features A a list of feature sets out of which at least one must be satisfied + A list of feature sets out of which at least one must be satisfied for this tool to apply.