Internal change
PiperOrigin-RevId: 429600430
diff --git a/site/en/docs/android-build-performance.md b/site/en/docs/android-build-performance.md
index 10d6681..bbb7209 100644
--- a/site/en/docs/android-build-performance.md
+++ b/site/en/docs/android-build-performance.md
@@ -18,7 +18,7 @@
Bazel writes a JSON trace profile by default to a file called
`command.profile.gz` in Bazel's output base.
-See the [JSON Profile documentation](/rules/performance#json-profile) for
+See the [JSON Profile documentation](/rules/performance#performance-profiling) for
how to read and interact with the profile.
**Persistent workers for Android build actions**.
diff --git a/site/en/docs/android-instrumentation-test.md b/site/en/docs/android-instrumentation-test.md
index 3b63984..8d01376 100644
--- a/site/en/docs/android-instrumentation-test.md
+++ b/site/en/docs/android-instrumentation-test.md
@@ -176,7 +176,7 @@
- `target_device`: An `android_device` target. This target describes the
specifications of the Android emulator which Bazel uses to create, launch and
run the tests. See the [section on choosing an Android
- device](#choosing-an-android_device) for more information.
+ device](#android-device-target) for more information.
The test app's `AndroidManifest.xml` must include [an `<instrumentation>`
tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings){: .external}.
diff --git a/site/en/docs/android-ndk.md b/site/en/docs/android-ndk.md
index 0d73282..f0eccad 100644
--- a/site/en/docs/android-ndk.md
+++ b/site/en/docs/android-ndk.md
@@ -98,7 +98,7 @@
Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
targeted for the `armeabi-v7a` ABI by default. To change this or build for
multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-the-target-abi).
+ABI](#configuring-target-abi).
## Example setup {:#example-setup}
@@ -228,7 +228,7 @@
```
Read more about passing compiler and linker flags with `--cxxopt`, `--copt`, and
-`--linkopt` in the [User Manual](/docs/user-manual#flag--cxxopt).
+`--linkopt` in the [User Manual](/docs/user-manual#cxxopt).
Compiler and linker flags can also be specified as attributes in `cc_library`
using `copts` and `linkopts`. For example:
@@ -386,7 +386,7 @@
Note: All of the targets on the command line must be compatible with
building for Android when specifying these flags, which may make it difficult to
-use [Bazel wild-cards](/reference/command-line-reference#target-pattern-syntax) like
+use [Bazel wild-cards](/docs/build#specifying-build-targets) like
`/...` and `:all`.
These flags can be put into a `bazelrc` config (one for each ABI), in
diff --git a/site/en/docs/aquery.md b/site/en/docs/aquery.md
index 745ace8..21c5b9c 100644
--- a/site/en/docs/aquery.md
+++ b/site/en/docs/aquery.md
@@ -304,7 +304,7 @@
`AspectClass` could be the name of the Aspect class (for native Aspects) or
`bzl_file%aspect_name` (for Starlark Aspects). `AspectDescriptor` are
sorted in topological order of the
-[dependency graph](/rules/aspects#aspect-basics).
+[dependency graph](rules/aspects#aspect_basics).
### Linking with the JSON profile {:#linking-with-json-profile}
diff --git a/site/en/docs/bazel-and-apple.md b/site/en/docs/bazel-and-apple.md
index 028131e..1be6b80 100644
--- a/site/en/docs/bazel-and-apple.md
+++ b/site/en/docs/bazel-and-apple.md
@@ -64,14 +64,14 @@
the newest available Xcode version. This is appropriate for local execution.
If you are performing remote builds, you should set `--xcode_config` to an
-[`xcode_config`](/reference/be/workspace#xcode_config)
+[`xcode_config`](/reference/be/objective-c#xcode_config)
target whose `versions` attribute is a list of remotely available
-[`xcode_version`](/reference/be/workspace#xcode_version)
+[`xcode_version`](/reference/be/objective-c#xcode_version)
targets, and whose `default` attribute is one of these
-[`xcode_versions`](/reference/be/workspace#xcode_version).
+[`xcode_versions`](/reference/be/objective-c#xcode_version).
If you are using dynamic execution, you should set `--xcode_config` to an
-[`xcode_config`](/reference/be/workspace#xcode_config)
+[`xcode_config`](/reference/be/objective-c#xcode_config)
target whose `remote_versions` attribute is an
[`available_xcodes`](/reference/be/workspace#available_xcodes)
target containing the remotely available Xcode versions, and whose
diff --git a/site/en/docs/bazel-and-java.md b/site/en/docs/bazel-and-java.md
index bb92ce0..b75afa3 100644
--- a/site/en/docs/bazel-and-java.md
+++ b/site/en/docs/bazel-and-java.md
@@ -36,7 +36,7 @@
`.bazelrc` file, where `{ver}` is for example `11`. Bazel repository owners
should set this flag so that Bazel and its users can reference the source code's
Java version number. For more details, see
-[Java language version flag](/docs/user-manual#flag--java_language_version).
+[Java language version flag](/docs/user-manual#java-language-version).
### Configuring the JVM used to execute and test the code {:#config-jvm}
@@ -58,7 +58,7 @@
To create a hermetic compile, you can use command line flag
`--java_runtime_version=remotejdk_11`. The code is compiled for, executed, and
tested on the JVM downloaded from a remote repository. For more details, see
-[Java runtime version flag](/docs/user-manual#flag--java_runtime_version).
+[Java runtime version flag](/docs/user-manual#java_runtime_version).
### Configuring compilation and execution of build tools in Java {:#config-build-tools-java}
@@ -79,7 +79,7 @@
however, mind that this may not work on JDK of arbitrary vendors.
For more details, see
-[configuring Java toolchains](#Configuring-the-Java-toolchains).
+[configuring Java toolchains](#config-java-toolchains).
## Best practices {:#best-practices}
@@ -232,7 +232,7 @@
You can reconfigure the compilation by adding `default_java_toolchain` macro to
a `BUILD` file and registering it either by adding `register_toolchain` rule to
the `WORKSPACE` file or by using
-[`--extra_toolchains`](/docs/user-manual#flag--extra_toolchains) flag.
+[`--extra_toolchains`](/docs/user-manual#extra-toolchains) flag.
The toolchain is only used when the `source_version` attribute matches the
value specified by `--java_language_version` flag.
diff --git a/site/en/docs/build.md b/site/en/docs/build.md
index 1c2d715..3eba5bc 100644
--- a/site/en/docs/build.md
+++ b/site/en/docs/build.md
@@ -21,20 +21,20 @@
### Available commands {:#available-commands}
* [`analyze-profile`](/docs/user-manual#analyze-profile): Analyzes build profile data.
-* [`aquery`](/docs/user-manual#aquery): Executes a query on the [post-analysis](#analysis-phase) action graph.
-* [`build`](#build): Builds the specified targets.
-* [`canonicalize-flags`](/docs/user-manual#canonicalize): Canonicalize Bazel flags.
+* [`aquery`](/docs/user-manual#aquery): Executes a query on the [post-analysis](#analysis) action graph.
+* [`build`](#bazel-build): Builds the specified targets.
+* [`canonicalize-flags`](/docs/user-manual#canonicalize-flags): Canonicalize Bazel flags.
* [`clean`](/docs/user-manual#clean): Removes output files and optionally stops the server.
-* [`cquery`](/docs/user-manual#query): Executes a [post-analysis](#analysis-phase) dependency graph query.
+* [`cquery`](/docs/cquery): Executes a [post-analysis](#analysis) dependency graph query.
* [`dump`](/docs/user-manual#dump): Dumps the internal state of the Bazel server process.
* [`help`](/docs/user-manual#help): Prints help for commands, or the index.
* [`info`](/docs/user-manual#info): Displays runtime info about the bazel server.
-* [`fetch`](#fetch): Fetches all external dependencies of a target.
+* [`fetch`](#fetching-external-dependencies): Fetches all external dependencies of a target.
* [`mobile-install`](/docs/user-manual#mobile-install): Installs apps on mobile devices.
-* [`query`](/docs/user-manual#query): Executes a dependency graph query.
-* [`run`](/docs/user-manual#run): Runs the specified target.
+* [`query`](/docs/query-how-to): Executes a dependency graph query.
+* [`run`](/docs/user-manual#running-executables): Runs the specified target.
* [`shutdown`](/docs/user-manual#shutdown): Stops the Bazel server.
-* [`test`](/docs/user-manual#test): Builds and runs the specified test targets.
+* [`test`](/docs/user-manual#running-tests): Builds and runs the specified test targets.
* [`version`](/docs/user-manual#version): Prints version information for Bazel.
### Getting help {:#getting-help}
@@ -42,7 +42,7 @@
* `bazel help {{ '<var>' }}command{{ '</var>' }}`: Prints help and options for
`{{ '<var>' }}command{{ '</var>' }}`.
* `bazel help `[`startup_options`](/docs/user-manual#startup-options): Options for the JVM hosting Bazel.
-* `bazel help `[`target-syntax`](#target-patterns): Explains the syntax for specifying targets.
+* `bazel help `[`target-syntax`](#specifying-build-targets): Explains the syntax for specifying targets.
* `bazel help info-keys`: Displays a list of keys used by the info command.
The `bazel` tool performs many functions, called commands. The most commonly
@@ -58,7 +58,7 @@
volume.
To build a program with Bazel, type `bazel build` followed by the
-[target](#target-patterns) you want to build.
+[target](#specifying-build-targets) you want to build.
```posix-terminal
bazel build //foo
@@ -666,7 +666,7 @@
The loading and analysis phases are fast because Bazel avoids unnecessary file
I/O at this stage, reading only BUILD files in order to determine the work to be
done. This is by design, and makes Bazel a good foundation for analysis tools,
-such as Bazel's [query](#query) command, which is implemented atop the loading
+such as Bazel's [query](/docs/query-how-to) command, which is implemented atop the loading
phase.
#### Execution phase {:#execution}
diff --git a/site/en/docs/configurable-attributes.md b/site/en/docs/configurable-attributes.md
index ba9e449..d205dbd 100644
--- a/site/en/docs/configurable-attributes.md
+++ b/site/en/docs/configurable-attributes.md
@@ -358,7 +358,7 @@
check against single values.
Platforms are still under development. See the
-[documentation](/docs/platforms-intro) for details.
+[documentation](/concepts/platforms-intro) for details.
## Combining `select()`s {:#combining-selects}
@@ -693,7 +693,7 @@
### Why doesn't select() work in macros? {:#faq-select-macro}
-select() *does* work in rules! See [Rules compatibility](#rules) for
+select() *does* work in rules! See [Rules compatibility](#rules-compatibility) for
details.
The key issue this question usually means is that select() doesn't work in
diff --git a/site/en/docs/coverage.md b/site/en/docs/coverage.md
index 080e9b8..76828f4 100644
--- a/site/en/docs/coverage.md
+++ b/site/en/docs/coverage.md
@@ -11,16 +11,16 @@
This page documents the general process for creating and viewing
coverage reports, and also features some language-specific notes for
languages whose configuration is well-known. It is best read by first
-reading [the general section](#Creating-a-coverage-report), and then
+reading [the general section](#creating-a-coverage-report), and then
reading about the requirements for a specific language. Note also the
-[remote execution section](#Remote-execution), which requires some
+[remote execution section](#remote-execution), which requires some
additional considerations.
While a lot of customization is possible, this document focuses on
producing and consuming [`lcov`][lcov] reports, which is currently the
most well-supported route.
-## Creating a coverage report
+## Creating a coverage report {:#creating-a-coverage-report}
### Preparation
@@ -84,7 +84,7 @@
For further help and information around the `genhtml` tool, or the
`lcov` coverage format, see [the lcov project][lcov].
-## Remote execution
+## Remote execution {:#remote-execution}
Running with remote test execution currently has a few caveats:
diff --git a/site/en/docs/cquery.md b/site/en/docs/cquery.md
index 9fbc729..a600a58 100644
--- a/site/en/docs/cquery.md
+++ b/site/en/docs/cquery.md
@@ -85,7 +85,7 @@
`cquery` requires a target to run through the [loading and analysis](/rules/concepts#evaluation-model)
phases. Unless otherwise specified, `cquery` parses the target(s) listed in the
-query expression. See [`--universe_scope`](#universe_scope-comma-separated-list)
+query expression. See [`--universe_scope`](#universe-scope)
for querying dependencies of top-level build targets.
## Configurations {:#configurations}
@@ -334,7 +334,7 @@
configured target. If you'd like to omit this information and get proto output
that is formatted exactly like query's proto output, set this flag to false.
-See [query's proto output documentation](/reference/query#output-proto)
+See [query's proto output documentation](/reference/query#output-formats)
for more proto output-related options.
Note: While selects are resolved both at the top level of returned
@@ -348,9 +348,9 @@
</pre>
This option generates output as a Graphviz-compatible .dot file. See `query`'s
-[graph output documentation](/reference/query#output-graph) for details. `cquery`
-also supports [`--graph:node_limit`](/reference/query#graph-node_limit-n) and
-[`--graph:factored`](/reference/query#no-graph-factored).
+[graph output documentation](/reference/query#display-result-graph) for details. `cquery`
+also supports [`--graph:node_limit`](/reference/query#graph-nodelimit) and
+[`--graph:factored`](/reference/query#graph-factored).
### Defining the output format using Starlark {:#output-format-definition}
@@ -506,7 +506,7 @@
evaluates _configured targets_ while `query` only
evaluates _targets_. This takes more time and uses more memory.
* `cquery`'s intepretation of
- the [query language](/reference/query#concepts) introduces ambiguity
+ the [query language](/reference/query) introduces ambiguity
that `query` avoids. For example,
if `"//foo"` exists in two configurations, which one
should `cquery "deps(//foo)"` use?
@@ -522,7 +522,7 @@
before the point where build actions would execute. The targets it
"builds" are by default selected from all labels that appear in the query
expression (this can be overridden
-with [`--universe_scope`](#universe_scope-comma-separated-list)). These
+with [`--universe_scope`](#universe-scope)). These
must have the same configuration.
While these generally share the top-level "target" configuration,
@@ -546,7 +546,7 @@
$ bazel cquery 'somepath(//foo, //bar)' --universe_scope=//foo
</pre>
-**No support for [`--output=xml`](/reference/query#output-xml).**
+**No support for [`--output=xml`](/reference/query#xml).**
**Non-deterministic output.**
diff --git a/site/en/docs/creating-workers.md b/site/en/docs/creating-workers.md
index a64955a..bc700bd 100644
--- a/site/en/docs/creating-workers.md
+++ b/site/en/docs/creating-workers.md
@@ -15,8 +15,8 @@
The worker implementation has two parts:
-* The [worker](#making-the-worker).
-* The [rule that uses the worker](#making-the-rule-that-uses-the-worker).
+* The [worker](#making-worker).
+* The [rule that uses the worker](#rule-uses-worker).
## Making the worker {:#making-worker}
diff --git a/site/en/docs/external.md b/site/en/docs/external.md
index e371089..722b162 100644
--- a/site/en/docs/external.md
+++ b/site/en/docs/external.md
@@ -253,7 +253,7 @@
Specifically:
* Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true`
- [startup option](user-manual#startup_options),
+ [startup option](/docs/user-manual#startup-options),
for example by adding the following line in your
[`.bazelrc` file](/docs/bazelrc):
@@ -262,7 +262,7 @@
* If you are running Java build targets that need to connect to the internet
as well (integration tests sometimes needs that), also use
`--jvmopt=-Djava.net.preferIPv6Addresses=true`
- [tool flag](user-manual#flags-options), for example by having the
+ [tool flag](/docs/user-manual#jvmopt), for example by having the
following line in your [`.bazelrc` file](/docs/bazelrc):
`build --jvmopt=-Djava.net.preferIPv6Addresses`
@@ -325,7 +325,7 @@
if the hash matches.
Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://bazel.build/designs/2016/10/11/distribution-artifact.html).
+artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
It does so by [collecting all the needed external
dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116){: .external}
in an internal
diff --git a/site/en/docs/memory-saving-mode.md b/site/en/docs/memory-saving-mode.md
index 33a8c71..1a8eab9 100644
--- a/site/en/docs/memory-saving-mode.md
+++ b/site/en/docs/memory-saving-mode.md
@@ -7,13 +7,13 @@
In certain situations, you may want Bazel to use minimal memory. You can set the
maximum heap via the startup flag
-[`--host_jvm_args`](/docs/user-manual#flag--host_jvm_args),
+[`--host_jvm_args`](/docs/user-manual#host-jvm-args),
like `--host_jvm_args=-Xmx2g`.
However, if your builds are big enough, Bazel may throw an `OutOfMemoryError`
(OOM) when it doesn't have enough memory. You can make Bazel use less memory, at
the cost of slower incremental builds, by passing the following command flags:
-[`--discard_analysis_cache`](/docs/user-manual#flag--discard_analysis_cache),
+[`--discard_analysis_cache`](/docs/user-manual#discard-analysis-cache),
`--nokeep_state_after_build`, and `--notrack_incremental_state`.
These flags will minimize the memory that Bazel uses in a build, at the cost of
diff --git a/site/en/docs/platforms.md b/site/en/docs/platforms.md
index 387573e..256db39 100644
--- a/site/en/docs/platforms.md
+++ b/site/en/docs/platforms.md
@@ -154,7 +154,7 @@
Incompatible tests in a [`test_suite`](/reference/be/general#test_suite) are
similarly skipped if the `test_suite` is specified on the command line with
-[`--expand_test_suites`](/reference/command-line-reference#expand-test_suites).
+[`--expand_test_suites`](/reference/command-line-reference#flag--expand_test_suites).
In other words, `test_suite` targets on the command line behave like `:all` and
`...`. Using `--noexpand_test_suites` prevents expansion and causes
`test_suite` targets with incompatible tests to also be incompatible.
@@ -227,7 +227,7 @@
You can use the
[`IncompatiblePlatformProvider`](/rules/lib/IncompatiblePlatformProvider)
in `bazel cquery`'s [Starlark output
-format](/docs/cquery#defining-the-output-format-using-starlark) to distinguish
+format](/docs/cquery#output-format-definition) to distinguish
incompatible targets from compatible ones.
This can be used to filter out incompatible targets. The example below will
diff --git a/site/en/docs/remote-caching-debug.md b/site/en/docs/remote-caching-debug.md
index 3d4e808..c44a7d1 100644
--- a/site/en/docs/remote-caching-debug.md
+++ b/site/en/docs/remote-caching-debug.md
@@ -20,7 +20,7 @@
Successful remote cache hits will show up in the status line, similar to
[Cache Hits rate with Remote
-Execution](/docs/remote-execution-caching-debug#checking-your-cache-hit-rate).
+Execution](/docs/remote-execution-caching-debug#check-cache-hits).
In the standard output of your Bazel run, you will see something like the
following:
@@ -70,7 +70,7 @@
`--verbose_failures`.
2. Follow the steps from [Troubleshooting cache hits for remote
- execution](/docs/remote-execution-caching-debug#troubleshooting-cache-hits) to
+ execution](/docs/remote-execution-caching-debug#troubleshooting_cache_hits) to
ensure that your cache-writing Bazel invocations are able to get cache hits
on the same machine and across machines.
@@ -85,6 +85,6 @@
cache-writing Bazel invocations.
c. Follow the same steps as to [ensure caching across
- machines](/docs/remote-execution-caching-debug#ensure-caching-across-machines),
+ machines](/docs/remote-execution-caching-debug#caching-across-machines),
to ensure caching from your cache-writing Bazel invocation to your
cache-reading Bazel invocation.
diff --git a/site/en/docs/remote-caching.md b/site/en/docs/remote-caching.md
index 41413ed..bf7daf3 100644
--- a/site/en/docs/remote-caching.md
+++ b/site/en/docs/remote-caching.md
@@ -66,7 +66,7 @@
You need to set up a server to act as the cache's backend. A HTTP/1.1
server can treat Bazel's data as opaque bytes and so many existing servers
can be used as a remote caching backend. Bazel's
-[HTTP Caching Protocol](#http-caching-protocol) is what supports remote
+[HTTP Caching Protocol](#http-caching) is what supports remote
caching.
You are responsible for choosing, setting up, and maintaining the backend
@@ -82,7 +82,7 @@
* [nginx](#nginx)
* [bazel-remote](#bazel-remote)
-* [Google Cloud Storage](#google-cloud-storage)
+* [Google Cloud Storage](#cloud-storage)
### nginx {:#nginx}
diff --git a/site/en/docs/remote-execution-caching-debug.md b/site/en/docs/remote-execution-caching-debug.md
index 4f6f486..ce940d3 100644
--- a/site/en/docs/remote-execution-caching-debug.md
+++ b/site/en/docs/remote-execution-caching-debug.md
@@ -32,7 +32,7 @@
(or a number lower than expected), run `bazel clean` followed by your build/test
command.
-## Troubleshooting cache hits
+## Troubleshooting cache hits {:#troubleshooting-cache-hits}
If you are not getting the cache hit rate you are expecting, do the following:
@@ -66,7 +66,7 @@
bazel {{ '<var>' }}--optional-flags{{ '</var>' }} build //{{ '<var>' }}your:target{{ '</var>' }} --execution_log_json_file=/tmp/exec1.json
```
- b. [Compare the execution logs](#comparing-the-execution-logs) between the
+ b. [Compare the execution logs](#compare-logs-the-execution-logs) between the
two runs. Ensure that the actions are identical across the two log files.
Discrepancies provide a clue about the changes that occurred between the
runs. Update your build to eliminate those discrepancies.
@@ -131,7 +131,7 @@
bazel ... build ... --execution_log_json_file=/tmp/exec2.json
```
-4. [Compare the execution logs](#comparing-the-execution-logs) for the two
+4. [Compare the execution logs](#compare-logs-the-execution-logs) for the two
runs. If the logs are not identical, investigate your build configurations
for discrepancies as well as properties from the host environment leaking
into either of the builds.
diff --git a/site/en/docs/remote-execution-rules.md b/site/en/docs/remote-execution-rules.md
index ba7d4e5..34c3193 100644
--- a/site/en/docs/remote-execution-rules.md
+++ b/site/en/docs/remote-execution-rules.md
@@ -38,10 +38,10 @@
build and test rules for remote execution and how to avoid them. It covers the
following topics:
-* [Invoking build tools through toolchain rules](#invoking-build-tools-through-toolchain-rules)
-* [Managing implicit dependencies](#managing-implicit-dependencies)
-* [Managing platform-dependent binaries](#managing-platform-dependent-binaries)
-* [Managing configure-style WORKSPACE rules](#managing-configure-style-workspace-rules)
+* [Invoking build tools through toolchain rules](#toolchain-rules)
+* [Managing implicit dependencies](#manage-dependencies)
+* [Managing platform-dependent binaries](#manage-binaries)
+* [Managing configure-style WORKSPACE rules](#manage-workspace-rules)
## Invoking build tools through toolchain rules {:#toolchain-rules}
diff --git a/site/en/docs/remote-execution-sandbox.md b/site/en/docs/remote-execution-sandbox.md
index c2b5b59..4184667 100644
--- a/site/en/docs/remote-execution-sandbox.md
+++ b/site/en/docs/remote-execution-sandbox.md
@@ -37,7 +37,7 @@
execution. However, this method will not detect local tools, states, and
data leaking into your build, which will cause problems with remote execution.
-* **[Troubleshooting in a Docker container.](#troubleshooting-in-a-docker-container)**
+* **[Troubleshooting in a Docker container.](#troubleshooting-docker-container)**
With this method, Bazel and its build actions run inside a Docker container,
which allows you to detect tools, states, and data leaking from the local
machine into the build in addition to imposing restrictions
@@ -95,8 +95,8 @@
executed remotely.
However, with this method, locally installed tools, binaries, and data may leak
-into into your build, especially if it uses [configure-style WORKSPACE rules](/docs/remote-execution-rules#managing-configure-style-workspace-rules).
-Such leaks will cause problems with remote execution; to detect them, [troubleshoot in a Docker container](#troubleshooting-in-a-docker-container)
+into into your build, especially if it uses [configure-style WORKSPACE rules](/docs/remote-execution-rules#manage-workspace-rules).
+Such leaks will cause problems with remote execution; to detect them, [troubleshoot in a Docker container](#troubleshooting-docker-container)
in addition to troubleshooting natively.
### Step 1: Run the build {:#run-build}
@@ -121,7 +121,7 @@
This flag enables verbose error messages. This error is typically caused by a
faulty Docker installation or lack of permissions to execute it under the
current user account. See the [Docker documentation](https://docs.docker.com/install/linux/linux-postinstall/){: .external}
-for more information. If problems persist, skip ahead to [Troubleshooting in a Docker container](#troubleshooting-in-a-docker-container).
+for more information. If problems persist, skip ahead to [Troubleshooting in a Docker container](#troubleshooting-docker-container).
### Step 2: Resolve detected issues {:#resolve-common-issues}
@@ -130,7 +130,7 @@
* **A file, tool, binary, or resource referenced by the Bazel runfiles tree is
missing.**. Confirm that all dependencies of the affected targets have been
[explicitly declared](/concepts/dependencies). See
- [Managing implicit dependencies](/docs/remote-execution-rules#managing-implicit-dependencies)
+ [Managing implicit dependencies](/docs/remote-execution-rules#manage-dependencies)
for more information.
* **A file, tool, binary, or resource referenced by an absolute path or the `PATH`
@@ -142,7 +142,7 @@
* **A binary execution fails.** One of the build rules is referencing a binary
incompatible with the execution environment (the Docker container). See
- [Managing platform-dependent binaries](/docs/remote-execution-rules#managing-platform-dependent-binaries)
+ [Managing platform-dependent binaries](/docs/remote-execution-rules#manage-binaries)
for more information. If you cannot resolve the issue, contact [bazel-discuss@google.com](mailto:bazel-discuss@google.com)
for help.
@@ -256,4 +256,4 @@
remote execution. See [Adapting Bazel Rules for Remote Execution](/docs/remote-execution-rules)
for possible causes and workarounds.
-* If the build fails for any other reason, see the troubleshooting steps in [Step 2: Resolve detected issues](#step-2-resolve-detected-issues).
+* If the build fails for any other reason, see the troubleshooting steps in [Step 2: Resolve detected issues](#start-container).
diff --git a/site/en/docs/scripts.md b/site/en/docs/scripts.md
index 8e4558b..bd21f77 100644
--- a/site/en/docs/scripts.md
+++ b/site/en/docs/scripts.md
@@ -86,7 +86,7 @@
### Reading the .bazelrc file {:#reading-bazelrc}
-By default, Bazel reads the [`.bazelrc` file](#bazelrc) from the base
+By default, Bazel reads the [`.bazelrc` file](/docs/bazelrc) from the base
workspace directory or the user's home directory. Whether or not this is
desirable is a choice for your script; if your script needs to be perfectly
hermetic (such as when doing release builds), you should disable reading the
diff --git a/site/en/docs/toolchain_resolution_implementation.md b/site/en/docs/toolchain_resolution_implementation.md
index 99c6645..b00c23e 100644
--- a/site/en/docs/toolchain_resolution_implementation.md
+++ b/site/en/docs/toolchain_resolution_implementation.md
@@ -36,7 +36,7 @@
1. If the execution platform is already set by the toolchain
transition, it will be selected first as described below.
-As discussed in [Toolchains and Configurations](/docs/toolchains#toolchains-and-configurations),
+As discussed in [Toolchains and Configurations](/docs/toolchains#toolchains_and_configurations),
the dependency from a target to a toolchain uses a special configuration that
forces the execution platform to be the same for both. Despite the name
"toolchain transition", this is not implemented as a configuration
diff --git a/site/en/docs/user-manual.md b/site/en/docs/user-manual.md
index ee63b89..1c9a9d7 100644
--- a/site/en/docs/user-manual.md
+++ b/site/en/docs/user-manual.md
@@ -167,7 +167,7 @@
This option takes an argument which is to be passed to the compiler for C source files
that are compiled in the host configuration. This is analogous to
-the [`--conlyopt`](#conlyopt) option, but applies only
+the [`--conlyopt`](#cconlyopt) option, but applies only
to the host configuration.
#### `--host_cxxopt={{ "<var>" }}cc-option{{ "</var>" }}` {:#host-cxxopt}
@@ -630,7 +630,7 @@
generate PIC code regardless of this flag's setting. So this flag is for cases
where users want PIC code explicitly generated for static links.
-#### `--android_resource_shrinking` {:#android-resource-shrinking}
+#### `--android_resource_shrinking` {:#flag--android_resource_shrinking}
Selects whether to perform resource shrinking for android_binary rules. Sets the default for the
[shrink_resources attribute](/reference/be/android#android_binary.shrink_resources) on
@@ -713,7 +713,7 @@
This does not select the Java compiler that is used to compile Java
source files. The compiler can be selected by settings the
-[`--java_toolchain`](#flag--java_toolchain) option.
+[`--java_toolchain`](#java-toolchain) option.
### Execution strategy {:#execution-strategy}
@@ -966,7 +966,7 @@
The `--save_temps` flag currently works only for cc_* rules.
To ensure that Bazel prints the location of the additional output files, check that
-your [`--show_result {{ "<var>" }}n{{ "</var>" }}`](#flag--show_result)
+your [`--show_result {{ "<var>" }}n{{ "</var>" }}`](#show-result)
setting is high enough.
#### `--build_tag_filters={{ "<var>" }}tag[,tag]*{{ "</var>" }}` {:#build-tag-filters}
@@ -1207,7 +1207,7 @@
See also [--verbose_failures](#verbose-failures), below.
For logging subcommands to a file in a tool-friendly format, see
-[--execution_log_json_file](/reference/command-line-reference#flag--execution_log_json_file")
+[--execution_log_json_file](/reference/command-line-reference#flag--execution_log_json_file)
and
[--execution_log_binary_file](/reference/command-line-reference#flag--execution_log_binary_file).
@@ -1455,7 +1455,7 @@
are strongly recommended:
* [`--bazelrc=/dev/null`](/docs/bazelrc)
-* [`--nokeep_state_after_build`](#keep-state-after-build)
+* [`--nokeep_state_after_build`](/reference/command-line-reference#flag--keep_state_after_build)
These options are also important:
@@ -1716,7 +1716,7 @@
#### Test selection {:#test-selection}
-As documented under [Output selection options](#output-selection-options),
+As documented under [Output selection options](#output-selection),
you can filter tests by [size](#test-size-filters),
[timeout](#test-timeout-filters),
[tag](#test-tag-filters), or
@@ -2030,8 +2030,8 @@
to `bazel info`, for
example `--cpu`, `--compilation_mode`,
etc. The `info` command accepts all
-the [options that control dependency
-analysis](#analysis-options), since some of these determine the location of the
+the options that control dependency
+analysis, since some of these determine the location of the
output directory of a build, the choice of compiler, etc.
* `bazel-bin`, `bazel-testlogs`,
diff --git a/site/en/docs/windows.md b/site/en/docs/windows.md
index 7624566..7235f31 100644
--- a/site/en/docs/windows.md
+++ b/site/en/docs/windows.md
@@ -332,4 +332,4 @@
If you are interested in details about how Bazel builds Python targets on
Windows, check out this [design
-doc](https://bazel.build/designs/2016/09/05/build-python-on-windows.html){: .external}.
+doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md){: .external}.
diff --git a/site/en/docs/workspace-log.md b/site/en/docs/workspace-log.md
index cab2a1d..1fc4734 100644
--- a/site/en/docs/workspace-log.md
+++ b/site/en/docs/workspace-log.md
@@ -42,10 +42,7 @@
* Sometimes functions might be re-executed, in which case the related
events will show up in the log multiple times.
-* Workspace rules log currently only logs Starlark events. Some native rules
- may cause non-hermetic behavior but not show up in this log. Examples of those
- rules include
- [maven_jar](/reference/be/workspace#maven_jar).
+* Workspace rules currently only log Starlark events.
Note: These particular rules do not cause hermiticity concerns as long
as a hash is specified.
