Docs: Apply code fonts for Bazel md files, part 2
PiperOrigin-RevId: 375102294
diff --git a/site/docs/cc-toolchain-config-reference.md b/site/docs/cc-toolchain-config-reference.md
index c6b6078..fddfeac 100644
--- a/site/docs/cc-toolchain-config-reference.md
+++ b/site/docs/cc-toolchain-config-reference.md
@@ -19,7 +19,7 @@
* Paths to the required tools such as gcc, ld, ar, objcopy, and so on.
* The built-in system include directories. Bazel needs these to validate that
all headers that were included in the source file were properly declared in
- the build file.
+ the `BUILD` file.
* The default sysroot.
* Which flags to use for compilation, linking, archiving.
* Which flags to use for the supported compilation modes (opt, dbg, fastbuild).
@@ -41,7 +41,7 @@
When a C++ target enters the analysis phase, Bazel selects the appropriate
-`cc_toolchain` target based on the BUILD file, and obtains the
+`cc_toolchain` target based on the `BUILD` file, and obtains the
`CcToolchainConfigInfo` provider from the target specified in the
`cc_toolchain.toolchain_config` attribute. The `cc_toolchain` target
passes this information to the C++ target through a `CcToolchainProvider`.
@@ -100,7 +100,7 @@
A feature is an entity that requires command-line flags, actions,
constraints on the execution environment, or dependency alterations. A feature
-can be something as simple as allowing BUILD files to select configurations of
+can be something as simple as allowing `BUILD` files to select configurations of
flags, such as `treat_warnings_as_errors`, or interact with the C++ rules and
include new compile actions and inputs to the compilation, such as
`header_modules` or `thin_lto`.
diff --git a/site/docs/configurable-attributes.md b/site/docs/configurable-attributes.md
index 18091ed..8d3dbe1 100644
--- a/site/docs/configurable-attributes.md
+++ b/site/docs/configurable-attributes.md
@@ -8,7 +8,7 @@
**_Configurable attributes_**, commonly known as [`select()`](
be/functions.html#select), is a Bazel feature that lets users toggle the values
-of BUILD rule attributes at the command line.
+of build rule attributes at the command line.
This can be used, for example, for a multiplatform library that automatically
chooses the appropriate implementation for the architecture, or for a
diff --git a/site/docs/external.md b/site/docs/external.md
index 9b30c1e..246d851 100644
--- a/site/docs/external.md
+++ b/site/docs/external.md
@@ -38,7 +38,7 @@
`/home/user/project1/BUILD` could depend on `@project2//:foo`.
The `WORKSPACE` file allows users to depend on targets from other parts of the
-filesystem or downloaded from the internet. It uses the same syntax as BUILD
+filesystem or downloaded from the internet. It uses the same syntax as `BUILD`
files, but allows a different set of rules called _repository rules_ (sometimes
also known as _workspace rules_). Bazel comes with a few [built-in repository
rules](be/workspace.html) and a set of [embedded Starlark repository
@@ -103,7 +103,7 @@
)
```
-`build_file` specifies a BUILD file to overlay on the existing project, for
+`build_file` specifies a `BUILD` file to overlay on the existing project, for
example:
```python
@@ -114,8 +114,8 @@
)
```
-You can then depend on `@coworkers_project//:some-lib` from your project's BUILD
-files.
+You can then depend on `@coworkers_project//:some-lib` from your project's
+`BUILD` files.
<a name="external-packages"></a>
### Depending on external packages
diff --git a/site/docs/generate-workspace.md b/site/docs/generate-workspace.md
index 246a064..c88f34e 100644
--- a/site/docs/generate-workspace.md
+++ b/site/docs/generate-workspace.md
@@ -11,7 +11,7 @@
# Generate External Dependencies from Maven Projects
The tool `generate_workspace` helps automate the process of writing
-the WORKSPACE file for a Java project. This tool is
+the `WORKSPACE` file for a Java project. This tool is
helpful when the list of external dependencies is long, such as when working
with [external transitive dependencies](external.html#transitive-dependencies).
@@ -77,7 +77,7 @@
To access external dependencies:
- 1. Add the following to your WORKSPACE file:
+ 1. Add the following to your `WORKSPACE` file:
```
load("//:generate_workspace.bzl", "generated_maven_jars")
@@ -108,14 +108,14 @@
as a dependency, the transitive dependencies are already included, and
so you don't need to list them manually.
- To access the libraries, add the following to a BUILD file:
+ To access the libraries, add the following to a `BUILD` file:
```
load("//:generate_workspace.bzl", "generated_java_libraries")
generated_java_libraries()
```
- The recommended location for this BUILD file is in a directory called
+ The recommended location for this `BUILD` file is in a directory called
`third_party`.
You can now access any of the Java library targets in
@@ -153,5 +153,5 @@
`javax.mail:mail:1.4`, `httpunit:httpunit:1.6`,
`org.springframework:spring-support:2.0.2`, and `org.slf4j:nlog4j:1.2.24`
all depend on `javax.activation`. However, two of these libraries wanted
- version 1.1 and three of them wanted 1.0.2. The WORKSPACE file is using
+ version 1.1 and three of them wanted 1.0.2. The `WORKSPACE` file is using
version 1.1, but that might not be the right version to use.
diff --git a/site/docs/guide.md b/site/docs/guide.md
index 117a396..ae77304 100644
--- a/site/docs/guide.md
+++ b/site/docs/guide.md
@@ -120,7 +120,7 @@
`build`, `test`, or `query`.
Whereas [labels](build-ref.html#labels) are used to specify individual targets,
-e.g. for declaring dependencies in BUILD files, Bazel's target patterns are a
+e.g. for declaring dependencies in `BUILD` files, Bazel's target patterns are a
syntax for specifying multiple targets: they are a generalization of the label
syntax for _sets_ of targets, using wildcards. In the simplest case, any valid
label is also a valid target pattern, identifying a set of exactly one target.
@@ -164,7 +164,7 @@
</tr>
<tr>
<td><code>//:all</code></td>
- <td>All targets in the top-level package, if there is a BUILD file at the
+ <td>All targets in the top-level package, if there is a `BUILD` file at the
root of the workspace.</td>
</tr>
</table>
@@ -418,7 +418,7 @@
All the inputs that specify the behavior and result of a given build can be
divided into two distinct categories. The first kind is the intrinsic
-information stored in the BUILD files of your project: the build rule, the
+information stored in the `BUILD` files of your project: the build rule, the
values of its attributes, and the complete set of its transitive dependencies.
The second kind is the external or environmental data, supplied by the user or
by the build tool: the choice of target architecture, compilation and linking
