Bazel DevSite: Fix product names and code snippets.
PiperOrigin-RevId: 435422344
diff --git a/site/command-line-reference-prefix.html b/site/command-line-reference-prefix.html
index 10968b7..ddde396 100644
--- a/site/command-line-reference-prefix.html
+++ b/site/command-line-reference-prefix.html
@@ -8,13 +8,13 @@
<h1 class="page-title">Command-Line Reference</h1>
<pre>
-bazel [<startup options>] <command> [<args>]
+blaze [<startup options>] <command> [<args>]
</pre>
or
<pre>
-bazel [<startup options>] <command> [<args>] -- [<target patterns>]
+blaze [<startup options>] <command> [<args>] -- [<target patterns>]
</pre>
See the <a href="/docs/build#specifying-build-targets">User's Guide</a> for the
@@ -23,7 +23,7 @@
<h2>Option Syntax</h2>
<p>
-Options can be passed to Bazel in different ways. Options that require a value
+Options can be passed to Blaze in different ways. Options that require a value
can be passed with either an equals sign or a space:
<pre>
--<option>=<value>
diff --git a/site/en/basics/artifact-based-builds.md b/site/en/basics/artifact-based-builds.md
index a5086cc..03d768a 100644
--- a/site/en/basics/artifact-based-builds.md
+++ b/site/en/basics/artifact-based-builds.md
@@ -50,8 +50,8 @@
## Understanding artifact-based build systems
-Google's build system, Bazel, was the first artifact-based build system. Bazel
-is the open-sourced version of Bazel.
+Google's build system, Blaze, was the first artifact-based build system. Bazel
+is the open-sourced version of Blaze.
Here’s what a buildfile (normally named `BUILD`) looks like in Bazel:
diff --git a/site/en/basics/distributed-builds.md b/site/en/basics/distributed-builds.md
index 32040d3..324b343 100644
--- a/site/en/basics/distributed-builds.md
+++ b/site/en/basics/distributed-builds.md
@@ -116,7 +116,8 @@
usage, and the system is able to build twice as fast compared to when we stored
all build output on the developer’s local disk.
-Google’s remote execution system is called Forge. A Forge client in Bazel called
+Google’s remote execution system is called Forge. A Forge client in Blaze
+(Bazel's internal equivalent) called
the Distributor sends requests for each action to a job running in our
datacenters called the Scheduler. The Scheduler maintains a cache of action
results, allowing it to return a response immediately if the action has already
diff --git a/site/en/basics/task-based-builds.md b/site/en/basics/task-based-builds.md
index f4549b2..555e48b 100644
--- a/site/en/basics/task-based-builds.md
+++ b/site/en/basics/task-based-builds.md
@@ -211,5 +211,5 @@
engineers and put it back in the hands of the system and reconceptualize the
role of the system not as running tasks, but as producing artifacts.
-This approach led to the creation of artifact-based build systems, like Bazel
+This approach led to the creation of artifact-based build systems, like Blaze
and Bazel.
diff --git a/site/en/community/roadmaps-starlark.md b/site/en/community/roadmaps-starlark.md
index b2bd751..3359103 100644
--- a/site/en/community/roadmaps-starlark.md
+++ b/site/en/community/roadmaps-starlark.md
@@ -66,7 +66,7 @@
Build health and Best practices:
-* Allow targets to track their macro call stack, for exporting via bazel query
+* Allow targets to track their macro call stack, for exporting via `bazel query`
* Implement `--incompatible_no_implicit_file_export`
* Remove the deprecated depset APIs (#5817, #10313, #9017).
* Add a cross file analyzer in Buildifier, implement a check for deprecated
diff --git a/site/en/contribute/codebase.md b/site/en/contribute/codebase.md
index ddaf665..2a67e71 100644
--- a/site/en/contribute/codebase.md
+++ b/site/en/contribute/codebase.md
@@ -70,8 +70,8 @@
implemented using an elaborate locking mechanism with parts in C++ and parts in
Java. There is some infrastructure for running multiple commands in parallel,
since the inability to run `bazel version` in parallel with another command
-is somewhat embarrassing. The main blocker is the life cycle of `BazelModule`s
-and some state in `BazelRuntime`.
+is somewhat embarrassing. The main blocker is the life cycle of `BlazeModule`s
+and some state in `BlazeRuntime`.
At the end of a command, the Bazel server transmits the exit code the client
should return. An interesting wrinkle is the implementation of `bazel run`: the
@@ -86,7 +86,7 @@
The source code of the client is under `src/main/cpp` and the protocol used to
communicate with the server is in `src/main/protobuf/command_server.proto` .
-The main entry point of the server is `BazelRuntime.main()` and the gRPC calls
+The main entry point of the server is `BlazeRuntime.main()` and the gRPC calls
from the client are handled by `GrpcServerImpl.run()`.
## Directory layout {:#directory-layout}
@@ -128,15 +128,15 @@
Once the Bazel server gets control and is informed about a command it needs to
execute, the following sequence of events happens:
-1. `BazelCommandDispatcher` is informed about the new request. It decides
+1. `BlazeCommandDispatcher` is informed about the new request. It decides
whether the command needs a workspace to run in (almost every command except
for ones that don't have anything to do with source code, such as version or
help) and whether another command is running.
2. The right command is found. Each command must implement the interface
- `BazelCommand` and must have the `@Command` annotation (this is a bit of an
+ `BlazeCommand` and must have the `@Command` annotation (this is a bit of an
antipattern, it would be nice if all the metadata a command needs was
- described by methods on `BazelCommand`)
+ described by methods on `BlazeCommand`)
3. The command line options are parsed. Each command has different command line
options, which are described in the `@Command` annotation.
@@ -218,7 +218,7 @@
### Repositories {:#repositories}
A "repository" is a source tree on which a developer works; it usually
-represents a single project. Bazel's ancestor, Bazel, operated on a monorepo,
+represents a single project. Bazel's ancestor, Blaze, operated on a monorepo,
that is, a single source tree that contains all source code used to run the build.
Bazel, in contrast, supports projects whose source code spans multiple
repositories. The repository from which Bazel is invoked is called the “main
@@ -246,7 +246,7 @@
Every repository is composed of packages, a collection of related files and
a specification of the dependencies. These are specified by a file called
`BUILD` or `BUILD.bazel`. If both exist, Bazel prefers `BUILD.bazel`; the reason
-why BUILD files are still accepted is that Bazel’s ancestor, Bazel, used this
+why BUILD files are still accepted is that Bazel’s ancestor, Blaze, used this
file name. However, it turned out to be a commonly used path segment, especially
on Windows, where file names are case-insensitive.
@@ -1102,15 +1102,15 @@
The life cycle of an action context is as follows:
-1. When the execution phase is started, `BazelModule` instances are asked what
+1. When the execution phase is started, `BlazeModule` instances are asked what
action contexts they have. This happens in the constructor of
`ExecutionTool`. Action context types are identified by a Java `Class`
instance that refers to a sub-interface of `ActionContext` and which
interface the action context must implement.
2. The appropriate action context is selected from the available ones and is
- forwarded to `ActionExecutionContext` and `BazelExecutor` .
+ forwarded to `ActionExecutionContext` and `BlazeExecutor` .
3. Actions request contexts using `ActionExecutionContext.getContext()` and
- `BazelExecutor.getStrategy()` (there should really be only one way to do
+ `BlazeExecutor.getStrategy()` (there should really be only one way to do
it…)
Strategies are free to call other strategies to do their jobs; this is used, for
@@ -1376,7 +1376,7 @@
* `bazel cquery` is used to investigate the configured target graph
* `bazel aquery` is used to investigate the action graph
-Each of these is implemented by subclassing `AbstractBazelQueryEnvironment`.
+Each of these is implemented by subclassing `AbstractBlazeQueryEnvironment`.
Additional additional query functions can be done by subclassing `QueryFunction`
. In order to allow streaming query results, instead of collecting them to some
data structure, a `query2.engine.Callback` is passed to `QueryFunction`, which
@@ -1398,8 +1398,8 @@
## The module system {:#module-system}
Bazel can be extended by adding modules to it. Each module must subclass
-`BazelModule` (the name is a relic of the history of Bazel when it used to be
-called Bazel) and gets information about various events during the execution of
+`BlazeModule` (the name is a relic of the history of Bazel when it used to be
+called Blaze) and gets information about various events during the execution of
a command.
They are mostly used to implement various pieces of "non-core" functionality
@@ -1408,12 +1408,12 @@
* Interfaces to remote execution systems
* New commands
-The set of extension points `BazelModule` offers is somewhat haphazard. Don't
+The set of extension points `BlazeModule` offers is somewhat haphazard. Don't
use it as an example of good design principles.
## The event bus {:#event-bus}
-The main way BazelModules communicate with the rest of Bazel is by an event bus
+The main way BlazeModules communicate with the rest of Bazel is by an event bus
(`EventBus`): a new instance is created for every build, various parts of Bazel
can post events to it and modules can register listeners for the events they are
interested in. For example, the following things are represented as events:
@@ -1427,7 +1427,7 @@
Some of these events are represented outside of Bazel in the
[Build Event Protocol](/docs/build-event-protocol)
-(they are `BuildEvent`s). This allows not only `BazelModule`s, but also things
+(they are `BuildEvent`s). This allows not only `BlazeModule`s, but also things
outside the Bazel process to observe the build. They are accessible either as a
file that contains protocol messages or Bazel can connect to a server (called
the Build Event Service) to stream events.
@@ -1581,7 +1581,7 @@
them to the client. These are then wrapped in an `OutErr` (an (stdout, stderr)
pair). Anything that needs to be printed on the console goes through these
streams. Then these streams are handed over to
-`BazelCommandDispatcher.execExclusively()`.
+`BlazeCommandDispatcher.execExclusively()`.
Output is by default printed with ANSI escape sequences. When these are not
desired (`--color=no`), they are stripped by an `AnsiStrippingOutputStream`. In
@@ -1637,8 +1637,8 @@
its own task stack. **TODO:** How does this work with actions and
continuation-passing style?
-The profiler is started and stopped in `BazelRuntime.initProfiler()` and
-`BazelRuntime.afterCommand()` respectively and attempts to be live for as long
+The profiler is started and stopped in `BlazeRuntime.initProfiler()` and
+`BlazeRuntime.afterCommand()` respectively and attempts to be live for as long
as possible so that we can profile everything. To add something to the profile,
call `Profiler.instance().profile()`. It returns a `Closeable`, whose closure
represents the end of the task. It's best used with try-with-resources
diff --git a/site/en/faq.md b/site/en/faq.md
index 65ce679..3a38a76 100644
--- a/site/en/faq.md
+++ b/site/en/faq.md
@@ -195,7 +195,7 @@
Open on issue [on GitHub](https://github.com/bazelbuild/bazel/issues){: .external}.
-## What’s up with the word “Bazel” in the codebase?
+## What’s up with the word “Blaze” in the codebase?
This is an internal name for the tool. Please refer to Bazel as Bazel.
diff --git a/site/en/reference/glossary.md b/site/en/reference/glossary.md
index 192ea4d..a878c33 100644
--- a/site/en/reference/glossary.md
+++ b/site/en/reference/glossary.md
@@ -87,7 +87,7 @@
(systemwide, per-workspace, per-user, or from a custom location), and a
`bazelrc` file may also import settings from other `bazelrc` files.
-### Bazel {:#bazel}
+### Blaze {:#blaze}
The Google-internal version of Bazel. Google’s main build system for its
mono-repository.
diff --git a/site/en/release/versioning.md b/site/en/release/versioning.md
index 11d5211..970a57a 100644
--- a/site/en/release/versioning.md
+++ b/site/en/release/versioning.md
@@ -63,7 +63,7 @@
Rolling releases are periodically cut from Bazel's main branch.
This release cadence involves a continuous delivery of preview releases of the
-next major Bazel version, which are in sync with Google’s internal Bazel
+next major Bazel version, which are in sync with Google’s internal Blaze
releases.
Note that a new rolling release can contain breaking changes that are
diff --git a/src/main/java/com/google/devtools/build/docgen/templates/attributes/binary/args.html b/src/main/java/com/google/devtools/build/docgen/templates/attributes/binary/args.html
index dd9316a..9e3bad5 100644
--- a/src/main/java/com/google/devtools/build/docgen/templates/attributes/binary/args.html
+++ b/src/main/java/com/google/devtools/build/docgen/templates/attributes/binary/args.html
@@ -7,14 +7,14 @@
</p>
<p>
-Command line arguments that Bazel will pass to the target when it is executed
+Command line arguments that Blaze will pass to the target when it is executed
either by the <code>run</code> command or as a test. These arguments are
-passed before the ones that are specified on the <code>bazel run</code> or
-<code>bazel test</code> command line.
+passed before the ones that are specified on the <code>blaze run</code> or
+<code>blaze test</code> command line.
</p>
<p>
<em class="harmful">NOTE: The arguments are not passed when you run the target
-outside of Bazel (for example, by manually executing the binary in
-<code>bazel-bin/</code>).</em>
+outside of Blaze (for example, by manually executing the binary in
+<code>blaze-bin/</code>).</em>
</p>
diff --git a/src/main/java/com/google/devtools/build/docgen/templates/attributes/binary/env.html b/src/main/java/com/google/devtools/build/docgen/templates/attributes/binary/env.html
index 8885781..2cc1857 100644
--- a/src/main/java/com/google/devtools/build/docgen/templates/attributes/binary/env.html
+++ b/src/main/java/com/google/devtools/build/docgen/templates/attributes/binary/env.html
@@ -3,7 +3,7 @@
<a href="${link make-variables}">"Make variable"</a> substitution</code></p>
<p>Specifies additional environment variables to set when the target is
- executed by <code>bazel run</code>.
+ executed by <code>blaze run</code>.
</p>
<p>
@@ -13,6 +13,6 @@
<p>
<em class="harmful">NOTE: The environment variables are not set when you run the target
-outside of Bazel (for example, by manually executing the binary in
-<code>bazel-bin/</code>).</em>
+outside of Blaze (for example, by manually executing the binary in
+<code>blaze-bin/</code>).</em>
</p>
diff --git a/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/restricted_to.html b/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/restricted_to.html
index 47580e7..daaeaf1 100644
--- a/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/restricted_to.html
+++ b/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/restricted_to.html
@@ -8,7 +8,7 @@
</p>
<p>
-This is part of Bazel's constraint system. See
+This is part of Blaze's constraint system. See
<code><a href="#common.compatible_with">compatible_with</a></code>
for details.
</p>
diff --git a/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/tags.html b/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/tags.html
index a8c0414..16dd55f 100644
--- a/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/tags.html
+++ b/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/tags.html
@@ -13,7 +13,7 @@
</p>
<p>
- Bazel modifies the behavior of its sandboxing code if it finds the following
+ Blaze modifies the behavior of its sandboxing code if it finds the following
keywords in the <code>tags</code> attribute of any test or <code>genrule</code>
target, or the keys of <code>execution_requirements</code> for any Starlark
action.
@@ -78,7 +78,7 @@
</p>
<p>
- Bazel modifies test running behavior if it finds the following keywords in the
+ Blaze modifies test running behavior if it finds the following keywords in the
<code>tags</code> attribute of the test rule:
</p>
@@ -98,8 +98,8 @@
affect target wildcard or test suite expansion in other contexts, including the
<code>query</code> command. Note that <code>manual</code> does not imply that a target should
not be built/run automatically by continuous build/test systems. For example, it may be
- desirable to exclude a target from <code>bazel test ...</code> because it requires specific
- Bazel flags, but still have it included in properly-configured presubmit or continuous test
+ desirable to exclude a target from <code>blaze test ...</code> because it requires specific
+ Blaze flags, but still have it included in properly-configured presubmit or continuous test
runs.
</li>
diff --git a/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/target_compatible_with.html b/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/target_compatible_with.html
index d85a7a7..d8d7362 100644
--- a/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/target_compatible_with.html
+++ b/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/target_compatible_with.html
@@ -12,7 +12,7 @@
the target is considered <em>incompatible</em>. Incompatible targets are
skipped for building and testing when the target pattern is expanded
(e.g. <code>//...</code>, <code>:all</code>). When explicitly specified on the
-command line, incompatible targets cause Bazel to print an error and cause a
+command line, incompatible targets cause Blaze to print an error and cause a
build or test failure.
</p>
diff --git a/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/toolchains.html b/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/toolchains.html
index 982c5e1..17083b5 100644
--- a/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/toolchains.html
+++ b/src/main/java/com/google/devtools/build/docgen/templates/attributes/common/toolchains.html
@@ -4,7 +4,7 @@
<p>
The set of targets whose <a href="${link make-variables}">Make variables</a> this target is
allowed to access. These targets are either instances of rules that provide
- <code>TemplateVariableInfo</code> or special targets for toolchain types built into Bazel. These
+ <code>TemplateVariableInfo</code> or special targets for toolchain types built into Blaze. These
include:
<ul>
diff --git a/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/args.html b/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/args.html
index c384583..47d4457 100644
--- a/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/args.html
+++ b/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/args.html
@@ -3,10 +3,10 @@
<a href="${link make-variables}">"Make variable"</a> substitution, and
<a href="#sh-tokenization">Bourne shell tokenization</a></code></p>
-<p>Command line arguments that Bazel passes to the target when it is
-executed with <code>bazel test</code>.
+<p>Command line arguments that Blaze passes to the target when it is
+executed with <code>blaze test</code>.
<p>
These arguments are passed before any <code>--test_arg</code> values
-specified on the <code>bazel test</code> command line.
+specified on the <code>blaze test</code> command line.
</p>
diff --git a/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/env.html b/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/env.html
index cc30d62..db605ab 100644
--- a/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/env.html
+++ b/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/env.html
@@ -8,7 +8,7 @@
<p>
Specifies additional environment variables to set when the test is executed by
- <code>bazel test</code>.
+ <code>blaze test</code>.
</p>
<p>
diff --git a/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/env_inherit.html b/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/env_inherit.html
index 22cceb4..306de88 100644
--- a/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/env_inherit.html
+++ b/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/env_inherit.html
@@ -1,7 +1,7 @@
<p><code>List of strings; optional</code></p>
<p>Specifies additional environment variables to inherit from the
- external environment when the test is executed by <code>bazel test</code>.
+ external environment when the test is executed by <code>blaze test</code>.
</p>
<p>
diff --git a/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/size.html b/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/size.html
index 28ea909..295eb6d 100644
--- a/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/size.html
+++ b/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/size.html
@@ -4,9 +4,9 @@
<p>Specifies a test's "heaviness": how much time/resources it needs to run.</p>
<p>Unit tests are considered "small", integration tests "medium", and end-to-end tests "large" or
-"enormous". Bazel uses the size to determine a default timeout, which can be overridden using the
+"enormous". Blaze uses the size to determine a default timeout, which can be overridden using the
<code>timeout</code> attribute. When the test is run locally, the <code>size</code> is additionally
-used for scheduling purposes: Bazel tries to respect <code>--local_{ram,cpu}_resources</code> and
+used for scheduling purposes: Blaze tries to respect <code>--local_{ram,cpu}_resources</code> and
not overwhelm the local machine by running lots of heavy tests at the same time.</p>
<p>Test sizes correspond to the following default timeouts and assumed peak local resource
diff --git a/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/timeout.html b/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/timeout.html
index 090bd73..697768b 100644
--- a/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/timeout.html
+++ b/src/main/java/com/google/devtools/build/docgen/templates/attributes/test/timeout.html
@@ -39,7 +39,7 @@
<p>
For times other than the above, the test timeout can be overridden with the
-<code>--test_timeout</code> bazel flag, e.g. for manually running under
+<code>--test_timeout</code> blaze flag, e.g. for manually running under
conditions which are known to be slow. The <code>--test_timeout</code> values
are in seconds. For example <code>--test_timeout=120</code> will set the test
timeout to two minutes.
