java_common support for plugins and IDEs - proposal
- [Java common refactoring](https://docs.google.com/document/d/10isTEK5W9iCPp4BIyGBrLY5iti3Waaam6EeGVSjq3r8/edit).
- IN PROGRESS
-* **java_library** rule is Starlarkified. IN
- PROGRESS
-
-
-Mid 2021
-
-* **java_binary and java_test** rules are Starlarkified.
-* **java_import and java_plugin** rules are Starlarkified.
-
-
-Fall 2021
-
-* Starlarkification of **java_\*_proto_library**
-* Remaining java rules are Starlarkified: **java_package_configuration,
- java_runtime, java_toolchain**.
-
-
-2022
-
-* Starlarkification of **java_common module**.
-
-## C++ rules
-
-Before C++ rules can be rewritten in Starlark some internal cleanups are needed.
-After that the C++ rules will be rewritten to Starlark piece by piece using
-builtins functionality. The API for C++ rules will not be made accessible from
-.bzl files until cc_module is rewritten in Starlark as well.
-
-
-Q1 2021
-
-* **Clang modules** support, DROPPED*
-* and **Include scanning** support, expected performance improvements from
- both DROPPED*
-* *We need more data to evaluate whether modules are really what is needed to
- improve performance.
-
-
-Q2 2021
-
-* Internal **Go rules** are Starlarkified IN
- PROGRESS
-* Objective-C rules **objc_library and objc_import** and native code related
- to them are Starlarkified IN PROGRESS
-
-
-Fall 2021 and beginning 2022
-
-* **cc_binary, cc_test and cc_library** are Starlarkified
-
-
-2022
-
-* Starlarkification of other C++ rules (**fdo_profile, cc_import,
- cc_toolchain, cc_toolchain_suite, fdo_prefetch_hints, cc_toolchain_alias,
- cc_libc_top_alias, cc_host_toolchain_alias,** +2)
-* Starlarkification of **cc_common module**
-
-## Misc
-
-
-Mid 2021
-
-* Aspect can propagate other aspects - proposal
- [Aspects Propagating Other Aspects](https://docs.google.com/document/d/1fVNyskIgMoiNeOOGt57LdDmEkAShkYUKYQTkf5yD1fA/edit).
- IN PROGRESS
-* Improve Starlark testing framework
diff --git a/6.5.0/community/roadmaps-starlark.mdx b/6.5.0/community/roadmaps-starlark.mdx
deleted file mode 100644
index cb3ef4c..0000000
--- a/6.5.0/community/roadmaps-starlark.mdx
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: 'Starlark Roadmap'
----
-
-
-*Last verified: 2020-04-21*
-([update history](https://github.com/bazelbuild/bazel-website/commits/master/roadmaps/starlark.md))
-
-*Point of contact:* [laurentlb](https://github.com/laurentlb)
-
-## Goal
-
-Our goal is to make Bazel more extensible. Users should be able to easily
-implement their own rules, and support new languages and tools. We want to
-improve the experience of writing and maintaining those rules.
-
-We focus on two areas:
-
-* Make the language and API simple, yet powerful.
-* Provide better tooling for reading, writing, updating, debugging, and testing the code.
-
-
-## Q2 2020
-
-Build health and Best practices:
-
-* P0. Discourage macros without have a name, and ensure the name is a unique
- string literal. This work is focused on Google codebase, but may impact
- tooling available publicly.
-* P0. Make Buildozer commands reliable with regard to selects and variables.
-* P1. Make Buildifier remove duplicates in lists that we don’t sort because of
- comments.
-* P1. Update Buildifier linter to recommend inlining trivial expressions.
-* P2. Study use cases for native.existing_rule[s]() and propose alternatives.
-* P2. Study use cases for the prelude file and propose alternatives.
-
-Performance:
-
-* P1. Optimize the Starlark interpreter using flat environments and bytecode
- compilation.
-
-Technical debt reduction:
-
-* P0. Add ability to port native symbols to Starlark underneath @bazel_tools.
-* P1. Delete obsolete flags (some of them are still used at Google, so we need to
- clean the codebase first): `incompatible_always_check_depset_elements`,
- `incompatible_disable_deprecated_attr_params`,
- `incompatible_no_support_tools_in_action_inputs`, `incompatible_new_actions_api`.
-* P1. Ensure the followin flags can be flipped in Bazel 4.0:
- `incompatible_disable_depset_items`, `incompatible_no_implicit_file_export`,
- `incompatible_run_shell_command_string`,
- `incompatible_restrict_string_escapes`.
-* P1. Finish lib.syntax work (API cleanup, separation from Bazel).
-* P2. Reduce by 50% the build+test latency of a trivial edit to Bazel’s Java packages.
-
-Community:
-
-* `rules_python` is active and well-maintained by the community.
-* Continuous support for rules_jvm_external (no outstanding pull requests, issue
- triage, making releases).
-* Maintain Bazel documentation infrastructure: centralize and canonicalize CSS
- styles across bazel-website, bazel-blog, docs
-* Bazel docs: add CI tests for e2e doc site build to prevent regressions.
-
-## Q1 2020
-
-Build health and Best practices:
-
-* 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
- functions.
-
-Performance:
-
-* Make Bazel’s own Java-based tests 2x faster.
-* Implement a Starlark CPU profiler.
-
-Technical debt reduction:
-
-* Remove 8 incompatible flags (after flipping them).
-* Finish lib.syntax cleanup work (break dependencies).
-* Starlark optimization: flat environment, bytecode compilation
-* Delete all serialization from analysis phase, if possible
-* Make a plan for simplifying/optimizing lib.packages
-
-Community:
-
-* Publish a Glossary containing definitions for all the Bazel-specific terms
diff --git a/6.5.0/community/sig.mdx b/6.5.0/community/sig.mdx
deleted file mode 100644
index 150fb41..0000000
--- a/6.5.0/community/sig.mdx
+++ /dev/null
@@ -1,157 +0,0 @@
----
-title: 'Bazel Special Interest Groups'
----
-
-
-Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/contribute/contribution-policy). This policy
-applies to [`bazelbuild`](http://github.com/bazelbuild).
-
-SIGs do their work in public. The ideal scope for a SIG covers a well-defined
-domain, where the majority of participation is from the community. SIGs may
-focus on community maintained repositories in `bazelbuild` (such as language
-rules) or focus on areas of code in the Bazel repository (such as Remote
-Execution).
-
-While not all SIGs will have the same level of energy, breadth of scope, or
-governance models, there should be sufficient evidence that there are community
-members willing to engage and contribute should the interest group be
-established. Before joining, review the group's work, and then get in touch
-with the SIG leader. Membership policies vary on a per-SIG basis.
-
-See the complete list of
-[Bazel SIGs](https://github.com/bazelbuild/community/tree/master/sigs).
-
-### Non-goals: What a SIG is not
-
-SIGs are intended to facilitate collaboration on shared work. A SIG is
-therefore:
-
-- *Not a support forum:* a mailing list and a SIG is not the same thing
-- *Not immediately required:* early on in a project's life, you may not know
- if you have shared work or collaborators
-- *Not free labor:* energy is required to grow and coordinate the work
- collaboratively
-
-Bazel Owners take a conservative approach to SIG creation—thanks to the ease of
-starting projects on GitHub, there are many avenues where collaboration can
-happen without the need for a SIG.
-
-## SIG lifecycle
-
-This section covers how to create a SIG.
-
-### Research and consultation
-
-To propose a new SIG group, first gather evidence for approval, as specified
-below. Some possible avenues to consider are:
-
-- A well-defined problem or set of problems the group would solve
-- Consultation with community members who would benefit, assessing both the
- benefit and their willingness to commit
-- For existing projects, evidence from issues and PRs that contributors care
- about the topic
-- Potential goals for the group to achieve
-- Resource requirements of running the group
-
-Even if the need for a SIG seems self-evident, the research and consultation is
-still important to the success of the group.
-
-### Create the new group
-
-The new group should follow the below process for chartering. In particular, it
-must demonstrate:
-
-- A clear purpose and benefit to Bazel (either around a sub-project or
- application area)
-- Two or more contributors willing to act as group leads, existence of other
- contributors, and evidence of demand for the group
-- Each group needs to use at least one publicly accessible mailing list. A SIG
- may reuse one of the public lists, such as
- [bazel-discuss](https://groups.google.com/g/bazel-discuss), ask for a list
- for @bazel.build, or create their own list
-- Resources the SIG initially requires (usually, mailing list and regular
- video call.)
-- SIGs can serve documents and files from their directory in
- [`bazelbuild/community`](https://github.com/bazelbuild/community)
- or from their own repository in the
- [`bazelbuild`](https://github.com/bazelbuild) GitHub
- organization. SIGs may link to external resources if they choose to organize
- their work outside of the `bazelbuild` GitHub organization
-- Bazel Owners approve or reject SIG applications and consult other
- stakeholders as necessary
-
-Before entering the formal parts of the process, you should consult with
-the Bazel product team, at product@bazel.build. Most SIGs require conversation
-and iteration before approval.
-
-The formal request for the new group is done by submitting a charter as a PR to
-[`bazelbuild/community`](https://github.com/bazelbuild/community),
-and including the request in the comments on the PR following the template
-below. On approval, the PR for the group is merged and the required resources
-created.
-
-### Template Request for New SIG
-
-To request a new SIG, use the template in the community repo:
-[SIG-request-template.md](https://github.com/bazelbuild/community/blob/main/governance/SIG-request-template.md).
-
-### Chartering
-
-To establish a group, you need a charter and must follow the Bazel
-[code of conduct](https://github.com/bazelbuild/bazel/blob/HEAD/CODE_OF_CONDUCT.md).
-Archives of the group will be public. Membership may either be open to all
-without approval, or available on request, pending approval of the group
-administrator.
-
-The charter must nominate an administrator. As well as an administrator, the
-group must include at least one person as lead (these may be the same person),
-who serves as point of contact for coordination as required with the Bazel
-product team.
-
-Group creators must post their charter to the group mailing list. The community
-repository in the Bazel GitHub organization archives such documents and
-policies. As groups evolve their practices and conventions, they should update
-their charters within the relevant part of the community repository.
-
-### Collaboration and inclusion
-
-While not mandated, the group should choose to make use of collaboration
-via scheduled conference calls or chat channels to conduct meetings. Any such
-meetings should be advertised on the mailing list, and notes posted to the
-mailing list afterwards. Regular meetings help drive accountability and progress
-in a SIG.
-
-Bazel product team members may proactively monitor and encourage the group to
-discussion and action as appropriate.
-
-### Launch a SIG
-
-Required activities:
-
-- Notify Bazel general discussion groups
- ([bazel-discuss](https://groups.google.com/g/bazel-discuss),
- [bazel-dev](https://groups.google.com/g/bazel-dev)).
-
-Optional activities:
-
-- Create a blog post for the Bazel blog
-
-### Health and termination of SIGs
-
-The Bazel owners make a best effort to ensure the health of SIGs. Bazel owners
-occasionally request the SIG lead to report on the SIG's work, to inform the
-broader Bazel community of the group's activity.
-
-If a SIG no longer has a useful purpose or interested community, it may be
-archived and cease operation. The Bazel product team reserves the right to
-archive such inactive SIGs to maintain the overall health of the project,
-though it is a less preferable outcome. A SIG may also opt to disband if
-it recognizes it has reached the end of its useful life.
-
-## Note
-
-*This content has been adopted from Tensorflow’s
-[SIG playbook](https://www.tensorflow.org/community/sig_playbook)
-with modifications.*
diff --git a/6.5.0/community/update.mdx b/6.5.0/community/update.mdx
deleted file mode 100644
index 2adbe86..0000000
--- a/6.5.0/community/update.mdx
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: 'Community updates'
----
-
-
-Join Bazel developer relations engineers for the monthly community update
-livestream, or catch up on past ones.
-
-Title | Date | Description | Speakers
--------- | -------- | -------- | --------
-[Roadmap Introduction](https://www.youtube.com/watch?v=gYrZDl7K9JM) | 5/19/2022 | The inaugural Bazel Community Update, introducing the community to some of Google's Bazel leadership to talk about the general state of the project and its upcoming roadmap | Sven Tiffe, Tony Aiuto, Radhika Advani
-[Hands-On with Bzlmod](https://www.youtube.com/watch?v=MuW5XNcFukE) | 6/23/2022 | This month, we're joined by Google engineers Yun Peng and Xudong Yang to talk about Bzlmod, the new dependency system that is expected to go GA later this year. We'll cover the motivation behind the change, the new capabilities it brings to the table, and walk through some examples of it in action. | Yun Peng, Xudong Yang
-[Extending Gazelle to generate BUILD files](https://www.youtube.com/watch?v=E1-U7EAfhXw) | 7/21/2022 | This month we're joined by Son Luong Ngoc who will be showing the Gazelle language extension system. We'll briefly touch on how it works under the covers, existing extensions, and how to go about writing your own extensions to ease the migration to Bazel. | Son Luong Ngoc
-[Using Bazel for JavaScript Projects](https://www.youtube.com/watch?v=RIfYqX0JJYk) | 8/18/2022 | In this update, Alex Eagle joins us to talk about running JavaScript build tooling under Bazel. We'll look at a couple of examples: a Vue.js frontend and Nest backend. We'll cover the migration to newer rules_js provided by Aspect, and study how the tooling allows for fetching third-party dependencies and resolving them in the Node.js runtime. | Alex Eagle
-[Like Peanut Butter & Jelly: Integrating Bazel with JetBrains IntelliJ](https://www.youtube.com/watch?v=wMrua-W-LC4) | 9/15/2022 | Bazel is awesome. IntelliJ is awesome. Naturally, they are more awesome together. Bazel IntelliJ plugin gurus Mai Hussien from Google and Justin Kaeser from JetBrains join us this month to give a live demo and walkthrough of the plugin's capabilities. Both new and experienced plugin users are welcome to come with questions. | Mai Hussien, Justin Kaeser
-[Bazel at scale for surgical robots](https://www.youtube.com/watch?v=kCs1xa45yjM) | 10/27/2022 | What do you do when CMake CI runs for four hours? Join Guillaume Maudoux of Tweag to learn about how they migrated large, embedded robotic applications to Bazel. Topics include configuring toolchains for cross compilation, improving CI performance, managing third-party dependencies, and creating a positive developer experience — everything needed to ensure that Bazel lives up to “{Fast, Correct} — Choose Two”. | Guillaume Maudoux
-TBD | 12/15/2022 | |
diff --git a/6.5.0/concepts/build-ref.mdx b/6.5.0/concepts/build-ref.mdx
deleted file mode 100644
index f26936a..0000000
--- a/6.5.0/concepts/build-ref.mdx
+++ /dev/null
@@ -1,115 +0,0 @@
----
-title: 'Workspaces, packages, and targets'
----
-
-
-Bazel builds software from source code organized in a directory tree called a
-workspace. Source files in the workspace are organized in a nested hierarchy of
-packages, where each package is a directory that contains a set of related
-source files and one `BUILD` file. The `BUILD` file specifies what software
-outputs can be built from the source.
-
-
-## Workspace
-
-A _workspace_ is a directory tree on your filesystem that contains the source
-files for the software you want to build. Each workspace has a text file named
-`WORKSPACE` which may be empty, or may contain references to [external
-dependencies](/docs/external) required to build the outputs.
-
-Directories containing a file called `WORKSPACE` are considered the root of a
-workspace. Therefore, Bazel ignores any directory trees in a workspace rooted at
-a subdirectory containing a `WORKSPACE` file, as they form another workspace.
-
-Bazel also supports `WORKSPACE.bazel` file as an alias of `WORKSPACE` file. If
-both files exist, `WORKSPACE.bazel` is used.
-
-### Repositories
-
-Code is organized in _repositories_. The directory containing the `WORKSPACE`
-file is the root of the main repository, also called `@`. Other, (external)
-repositories are defined in the `WORKSPACE` file using workspace rules, or
-generated from modules and extensions in the Bzlmod system. See [external
-dependencies overview](/external/overview) for more information.
-
-The workspace rules bundled with Bazel are documented in the [Workspace
-Rules](/reference/be/workspace) section in the [Build
-Encyclopedia](/reference/be/overview) and the documentation on [embedded
-Starlark repository rules](/rules/lib/repo/index).
-
-As external repositories are repositories themselves, they often contain a
-`WORKSPACE` file as well. However, these additional `WORKSPACE` files are
-ignored by Bazel. In particular, repositories depended upon transitively are not
-added automatically.
-
-## Packages
-
-The primary unit of code organization in a repository is the _package_. A
-package is a collection of related files and a specification of how they can be
-used to produce output artifacts.
-
-A package is defined as a directory containing a file named `BUILD` (or
-`BUILD.bazel`). A package includes all files in its directory, plus all
-subdirectories beneath it, except those which themselves contain a `BUILD` file.
-From this definition, no file or directory may be a part of two different
-packages.
-
-For example, in the following directory tree there are two packages, `my/app`,
-and the subpackage `my/app/tests`. Note that `my/app/data` is not a package, but
-a directory belonging to package `my/app`.
-
-```
-src/my/app/BUILD
-src/my/app/app.cc
-src/my/app/data/input.txt
-src/my/app/tests/BUILD
-src/my/app/tests/test.cc
-```
-
-## Targets
-
-A package is a container of _targets_, which are defined in the package's
-`BUILD` file. Most targets are one of two principal kinds, _files_ and _rules_.
-
-Files are further divided into two kinds. _Source files_ are usually written by
-the efforts of people, and checked in to the repository. _Generated files_,
-sometimes called derived files or output files, are not checked in, but are
-generated from source files.
-
-The second kind of target is declared with a _rule_. Each rule instance
-specifies the relationship between a set of input and a set of output files. The
-inputs to a rule may be source files, but they also may be the outputs of other
-rules.
-
-Whether the input to a rule is a source file or a generated file is in most
-cases immaterial; what matters is only the contents of that file. This fact
-makes it easy to replace a complex source file with a generated file produced by
-a rule, such as happens when the burden of manually maintaining a highly
-structured file becomes too tiresome, and someone writes a program to derive it.
-No change is required to the consumers of that file. Conversely, a generated
-file may easily be replaced by a source file with only local changes.
-
-The inputs to a rule may also include _other rules_. The precise meaning of such
-relationships is often quite complex and language- or rule-dependent, but
-intuitively it is simple: a C++ library rule A might have another C++ library
-rule B for an input. The effect of this dependency is that B's header files are
-available to A during compilation, B's symbols are available to A during
-linking, and B's runtime data is available to A during execution.
-
-An invariant of all rules is that the files generated by a rule always belong to
-the same package as the rule itself; it is not possible to generate files into
-another package. It is not uncommon for a rule's inputs to come from another
-package, though.
-
-Package groups are sets of packages whose purpose is to limit accessibility of
-certain rules. Package groups are defined by the `package_group` function. They
-have three properties: the list of packages they contain, their name, and other
-package groups they include. The only allowed ways to refer to them are from the
-`visibility` attribute of rules or from the `default_visibility` attribute of
-the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/reference/be/functions#package_group).
-
-
- Labels
-
diff --git a/6.5.0/concepts/platforms.mdx b/6.5.0/concepts/platforms.mdx
deleted file mode 100644
index b95d0a3..0000000
--- a/6.5.0/concepts/platforms.mdx
+++ /dev/null
@@ -1,459 +0,0 @@
----
-title: 'Building with Platforms'
----
-
-
-Bazel has sophisticated support for modeling [platforms][Platforms] and
-[toolchains][Toolchains]. Integrating this with real projects requires
-careful cooperation between code owners, rule maintainers, and core Bazel devs.
-
-This page summarizes the purpose of platforms and shows how to build with them.
-
-**tl;dr:** Bazel's platform and toolchain APIs are available but won't work
-everywhere until all language rules, `select()`s and other legacy references
-are updated. This work is ongoing. Eventually all builds will be platform-based.
-Read below to see where your builds fit.
-
-For more formal documentation, see:
-
-* [Platforms][Platforms]
-* [Toolchains][Toolchains]
-
-## Background
-
-*Platforms* and *toolchains* were introduced to *standardize* how software
-projects target different machines and build with the right language tools.
-
-This is a relatively recent addition to Bazel. It was
-[inspired][Inspiration]
-by the observation that language maintainers were *already* doing this in ad
-hoc, incompatible ways. For example, C++ rules use `--cpu` and `--crosstool_top`
-to set a build's target CPU and C++ toolchain. Neither of these correctly models
-a "platform". Historic attempts to do so caused awkward and inaccurate builds.
-These flags also don't control Java compilation, which evolved its own
-independent interface with `--java_toolchain`.
-
-Bazel is intended for large, multi-language, multi-platform projects. This
-demands more principled support for these concepts, including clear APIs that
-encourage language and project interoperability. This is what these new APIs are
-for.
-
-### Migration
-
-The platform and toolchain APIs only work when projects actually use them. This
-isn't trivial because a project's rule logic, toolchains, dependencies, and
-`select()`s have to support them. This requires a careful migration sequence
-to keep all projects and their dependencies working correctly.
-
-For example, Bazel's
-[C++ Rules] support platforms. But the [Apple Rules] don't. *Your* C++ project
-may not care about Apple. But others may. So
-it's not yet safe to globally enable platforms for all C++ builds.
-
-The remainder of this page describes this migration sequence and how and when
-your projects can fit in.
-
-## Goal
-
-Bazel's platform migration is complete when all projects build with the form:
-
-```posix-terminal
-bazel build //:myproject --platforms=//:myplatform
-```
-
-This implies:
-
-1. The rules your project uses can infer correct toolchains from
-`//:myplatform`.
-1. The rules your project's dependencies use can infer correct toolchains
-from `//:myplatform`.
-1. *Either* the projects depending on yours support `//:myplatform` *or* your
-project supports the legacy APIs (like `--crosstool_top`).
-1. `//:myplatform` references
-[common declarations][Common Platform Declaration]
-of `CPU`, `OS`, and other generic concepts that support automatic cross-project
-compatibility.
-1. All relevant projects'
-[`select()`s][select()]
-understand the machine properties implied by `//:myplatform`.
-1. `//:myplatform` is defined in a clear, reusable place: in your project's
-repo if the platform is unique to your project, otherwise somewhere all projects
-that may use this platform can find.
-
-The old APIs will be removed as soon as this goal is achieved. Then this will
-be the standard way projects select platforms and toolchains.
-
-## Should I use platforms?
-
-If you just want to build or cross-compile a project, you should follow the
-project’s official documentation.
-
-If you’re a project, language, or toolchain maintainer, you'll eventually want
-to support the new APIs. Whether you wait until the global migration is complete
-or opt in early depends on your specific value / cost needs:
-
-### Value
-
-* You can `select()` or choose toolchains on the exact properties you care
- about instead of hard-coded flags like `--cpu`. For example, multiple CPUs
- can support the [same instruction set](https://en.wikipedia.org/wiki/SSE4).
-* More correct builds. If you `select()` with `--cpu` in the above example, then
- add a new CPU that supports the same instruction set, the `select()`
- fails to recognize the new CPU. But a `select()` on platforms remains accurate.
-* Simpler user experience. All projects understand:
- `--platforms=//:myplatform`. No need for multiple language-specific
- flags on the command line.
-* Simpler language design. All languages share a common API for defining
- toolchains, using toolchains, and selecting the right toolchain for a platform.
-* Targets can be [skipped](/docs/platforms#skipping-incompatible-targets) in the
- build and test phase if they are incompatible with the target platform.
-
-### Costs
-
-* Dependent projects that don't yet support platforms might not automatically work
- with yours.
-* Making them work may require [additional temporary maintenance](#platform-mappings).
-* Co-existence of new and legacy APIs requires more careful user guidance to
- avoid confusion.
-* Canonical definitions for [common properties](#common-platform-properties) like
- `OS` and `CPU` are still evolving and may require extra initial contributions.
-* Canonical definitions for language-specific toolchains are still evolving and
- may require extra initial contributions.
-
-## API review
-
-A [`platform`][platform Rule] is a collection of
-[`constraint_value` targets][constraint_value Rule]:
-
-```python
-platform(
- name = "myplatform",
- constraint_values = [
- "@platforms//os:linux",
- "@platforms//cpu:arm",
- ],
-)
-```
-
-A [`constraint_value`][constraint_value Rule] is a machine
-property. Values of the same "kind" are grouped under a common
-[`constraint_setting`][constraint_setting Rule]:
-
-```python
-constraint_setting(name = "os")
-constraint_value(
- name = "linux",
- constraint_setting = ":os",
-)
-constraint_value(
- name = "mac",
- constraint_setting = ":os",
-)
-```
-
-A [`toolchain`][Toolchains] is a [Starlark rule][Starlark rule]. Its
-attributes declare a language's tools (like `compiler =
-"//mytoolchain:custom_gcc"`). Its [providers][Starlark Provider] pass
-this information to rules that need to build with these tools.
-
-Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
-
-When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
-automatically selects a toolchain that can run on the build machine and
-build binaries for `//:myplatform`. This is known as *toolchain resolution*.
-
-The set of available toolchains can be registered in the `WORKSPACE` with
-[`register_toolchains`][register_toolchains Function] or at the
-command line with [`--extra_toolchains`][extra_toolchains Flag].
-
-See [here][Toolchains] for a deeper dive.
-
-## Status
-
-Current platform support varies among languages. All of Bazel's major rules are
-moving to platforms. But this process will take time. This is for three main reasons:
-
-1. Rule logic must be updated to get tool info from the new [toolchain
-API][Toolchains] (`ctx.toolchains`) and stop reading legacy settings like
-`--cpu` and `--crosstool_top`. This is relatively straightforward.
-
-1. Toolchain maintainers must define toolchains and make them accessible to
- users (in GitHub repositories and `WORKSPACE` entries).
- This is technically straightforward but must be intelligently organized to
- maintain an easy user experience.
-
- Platform definitions are also necessary (unless you build for the same machine
- Bazel runs on). Generally, projects should define their own platforms.
-
-1. Existing projects must be migrated. `select()`s and
- [transitions][Starlark transitions] also have to be
- migrated. This is the biggest challenge. It's particularly challenging for
- multi-language projects (which may fail if *all* languages can't read
- `--platforms`).
-
-If you're designing a new rule set, you must support platforms from the
-beginning. This automatically makes your rules compatible with other
-rules and projects, with increasing value as the platform API becomes
-more ubiquitous.
-
-### Common platform properties
-
-Platform properties like `OS` and `CPU` that are common across projects should
-be declared in a standard, centralized place. This encourages cross-project
-and cross-language compatibility.
-
-For example, if *MyApp* has a `select()` on `constraint_value`
-`@myapp//cpus:arm` and *SomeCommonLib* has a `select()` on
-`@commonlib//constraints:arm`, these trigger their "arm" modes with incompatible
-criteria.
-
-Globally common properties are declared in the
-[`@platforms`](https://github.com/bazelbuild/platforms) repo
-(so the canonical label for the above example is `@platforms//cpu:arm`).
-Language-common properties should be declared in the repos of their respective
-languages.
-
-### Default platforms
-
-Generally, project owners should define explicit
-[platforms][Defining Constraints and Platforms] to describe the
-kinds of machines they want to build for. These are then triggered with
-`--platforms`.
-
-When `--platforms` isn't set, Bazel defaults to a `platform` representing the
-local build machine. This is auto-generated at `@local_config_platform//:host`
-so there's no need to explicitly define it. It maps the local machine's `OS`
-and `CPU` with `constraint_value`s declared in
-[`@platforms`](https://github.com/bazelbuild/platforms).
-
-### C++
-
-Bazel's C++ rules use platforms to select toolchains when you set
-`--incompatible_enable_cc_toolchain_resolution`
-([#7260](https://github.com/bazelbuild/bazel/issues/7260)).
-
-This means you can configure a C++ project with:
-
-```posix-terminal
-bazel build //:my_cpp_project --platforms=//:myplatform
-```
-
-instead of the legacy:
-
-```posix-terminal
-bazel build //:my_cpp_project` --cpu=... --crosstool_top=... --compiler=...
-```
-
-If your project is pure C++ and not depended on by non-C++ projects, you can use
-platforms safely as long as your [`select`](#select)s and
-[transitions](#transitions) are compatible. See
-[#7260](https://github.com/bazelbuild/bazel/issues/7260) and
-[Configuring C++ toolchains] for more guidance.
-
-This mode is not enabled by default. This is because Apple projects
-still configure C++ dependencies with `--cpu` and `--crosstool_top`
-([example](https://github.com/bazelbuild/bazel/issues/8716#issuecomment-507230303)). So this depends on the Apple rules migrating to platforms.
-
-### Java
-
-Bazel's Java rules use platforms.
-
-This replaces legacy flags `--java_toolchain`, `--host_java_toolchain`,
-`--javabase`, and `--host_javabase`.
-
-To learn how to use the configuration flags, see the [Bazel and Java](/docs/bazel-and-java) manual.
-For additional information, see the [Design document](https://docs.google.com/document/d/1MVbBxbKVKRJJY7DnkptHpvz7ROhyAYy4a-TZ-n7Q0r4).
-
-If you are still using legacy flags, follow the migration process in [Issue #7849](https://github.com/bazelbuild/bazel/issues/7849).
-
-### Android
-
-Bazel's Android rules use platforms to select toolchains when you set
-`--incompatible_enable_android_toolchain_resolution`.
-
-This is not enabled by default. But migration is well on its way.
-
-### Apple
-
-Bazel's Apple rules do not yet support platforms to select Apple toolchains.
-
-They also don't support platform-enabled C++ dependencies because they use the
-legacy `--crosstool_top` to set the C++ toolchain. Until this is migrated, you
-can mix Apple projects with platorm-enabled C++ with [platform
-mappings](#platform-mappings)
-([example](https://github.com/bazelbuild/bazel/issues/8716#issuecomment-516572378)).
-
-### Other languages
-
-* Bazel's [Rust rules](https://github.com/bazelbuild/rules_rust) fully support
-platforms.
-* Bazel's [Go rules](https://github.com/bazelbuild/rules_go) fully support
-platforms
-([details](https://github.com/bazelbuild/rules_go#how-do-i-cross-compile)).
-
-If you're designing rules for a new language, use platforms
-to select your language's toolchains. See the
-[toolchains documentation](/docs/toolchains) for a good walkthrough.
-
-### `select()`
-
-Projects can [`select()`][select()] on
-[`constraint_value` targets][constraint_value Rule] but not complete
-platforms. This is intentional so that `select()`s supports as wide a variety
-of machines as possible. A library with `ARM`-specific sources should support
-*all* `ARM`-powered machines unless there's reason to be more specific.
-
-To select on one or more `constraint_value`s, use:
-
-```python
-config_setting(
- name = "is_arm",
- constraint_values = [
- "@platforms//cpu:arm",
- ],
-)
-```
-
-This is equivalent to traditionally selecting on `--cpu`:
-
-```python
-config_setting(
- name = "is_arm",
- values = {
- "cpu": "arm",
- },
-)
-```
-
-More details [here][select() Platforms].
-
-`select`s on `--cpu`, `--crosstool_top`, etc. don't understand `--platforms`. When
-migrating your project to platforms, you must either convert them to
-`constraint_values` or use [platform mappings](#platform-mappings) to support
-both styles through the migration window.
-
-### Transitions
-
-[Starlark transitions][Starlark transitions] change
-flags down parts of your build graph. If your project uses a transition that
-sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
-`--platforms` won't see these changes.
-
-When migrating your project to platforms, you must either convert changes like
-`return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles through the migration
-window.
-
-## How to use platforms today
-
-If you just want to build or cross-compile a project, you should follow the
-project's official documentation. It's up to language and project maintainers to
-determine how and when to integrate with platforms, and what value that offers.
-
-If you're a project, language, or toolchain maintainer and your build doesn't
-use platforms by default, you have three options (besides waiting for the global
-migration):
-
-1. Flip on the "use platforms" flag for your project's languages ([if they have
- one](#status)) and do whatever testing you need to see if the projects you care
- about work.
-
-1. If the projects you care about still depend on legacy flags like `--cpu` and
- `--crosstool_top`, use these together with `--platforms`:
-
- ```posix-terminal
- bazel build //:my_mixed_project --platforms==//:myplatform --cpu=... --crosstool_top=...
- ```
-
- This has some maintenance cost (you have to manually make sure the settings
- match). But this should work in the absence of renegade
- [transitions](#transitions).
-
-1. Write [platform mappings](#platform-mappings) to support both styles by
- mapping `--cpu`-style settings to corresponding platforms and vice versa.
-
-### Platform mappings
-
-*Platform mappings* is a temporary API that lets platform-powered and
-legacy-powered logic co-exist in the same build through the latter's deprecation
-window.
-
-A platform mapping is a map of either a `platform()` to a
-corresponding set of legacy flags or the reverse. For example:
-
-```python
-platforms:
- # Maps "--platforms=//platforms:ios" to "--cpu=ios_x86_64 --apple_platform_type=ios".
- //platforms:ios
- --cpu=ios_x86_64
- --apple_platform_type=ios
-
-flags:
- # Maps "--cpu=ios_x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
- --cpu=ios_x86_64
- --apple_platform_type=ios
- //platforms:ios
-
- # Maps "--cpu=darwin --apple_platform_type=macos" to "//platform:macos".
- --cpu=darwin
- --apple_platform_type=macos
- //platforms:macos
-```
-
-Bazel uses this to guarantee all settings, both platform-based and
-legacy, are consistently applied throughout the build, including through
-[transitions](#transitions).
-
-By default Bazel reads mappings from the `platform_mappings` file in your
-workspace root. You can also set
-`--platform_mappings=//:my_custom_mapping`.
-
-See
-[here](https://docs.google.com/document/d/1Vg_tPgiZbSrvXcJ403vZVAGlsWhH9BUDrAxMOYnO0Ls/edit)
-for complete details.
-
-## Questions
-
-For general support and questions about the migration timeline, contact
-[bazel-discuss@googlegroups.com](https://groups.google.com/forum/#!forum/bazel-discuss)
-or the owners of the appropriate rules.
-
-For discussions on the design and evolution of the platform/toolchain APIs,
-contact
-[bazel-dev@googlegroups.com](https://groups.google.com/forum/#!forum/bazel-dev).
-
-## See also
-
-* [Configurable Builds - Part 1](https://blog.bazel.build/2019/02/11/configurable-builds-part-1.html)
-* [Platforms]
-* [Toolchains]
-* [Bazel Platforms Cookbook](https://docs.google.com/document/d/1UZaVcL08wePB41ATZHcxQV4Pu1YfA1RvvWm8FbZHuW8/)
-* [`hlopko/bazel_platforms_examples`](https://github.com/hlopko/bazel_platforms_examples)
-* [Example C++ custom toolchain](https://github.com/gregestren/snippets/tree/master/custom_cc_toolchain_with_platforms)
-
-[Platforms]: /docs/platforms
-[Toolchains]: /docs/toolchains
-[Inspiration]: https://blog.bazel.build/2019/02/11/configurable-builds-part-1.html
-[C++ Rules]: /docs/bazel-and-cpp
-[Android Rules]: /docs/bazel-and-android
-[Apple Rules]: https://github.com/bazelbuild/rules_apple
-[Common Platform Declarations]: https://github.com/bazelbuild/platforms#motivation
-[select()]: /docs/configurable-attributes
-[select() Platforms]: /docs/configurable-attributes#platforms
-[platform Rule]: /reference/be/platform#platform
-[constraint_value Rule]: /reference/be/platform#constraint_value
-[constraint_setting Rule]: /reference/be/platform#constraint_setting
-[Starlark rule]: /rules/rules
-[Starlark provider]: /rules/rules#providers
-[target_compatible_with Attribute]: /reference/be/platform#toolchain.target_compatible_with
-[exec_compatible_with Attribute]: /reference/be/platform#toolchain.exec_compatible_with
-[register_toolchains Function]: /rules/lib/globals#register_toolchains
-[extra_toolchains Flag]: /reference/command-line-reference#flag--extra_toolchains
-[Starlark transitions]: /rules/config#user-defined-transitions
-[Defining Constraints and Platforms]: /docs/platforms#constraints-platforms
-[Configuring C++ toolchains]: /tutorials/cc-toolchain-config
diff --git a/6.5.0/concepts/visibility.mdx b/6.5.0/concepts/visibility.mdx
deleted file mode 100644
index 082b855..0000000
--- a/6.5.0/concepts/visibility.mdx
+++ /dev/null
@@ -1,461 +0,0 @@
----
-title: 'Visibility'
----
-
-
-This page covers Bazel's two visibility systems:
-[target visibility](#target-visibility) and [load visibility](#load-visibility).
-
-Both types of visibility help other developers distinguish between your
-library's public API and its implementation details, and help enforce structure
-as your workspace grows. You can also use visibility when deprecating a public
-API to allow current users while denying new ones.
-
-## Target visibility
-
-**Target visibility** controls who may depend on your target — that is, who may
-use your target's label inside an attribute such as `deps`.
-
-A target `A` is visible to a target `B` if they are in the same package, or if
-`A` grants visibility to `B`'s package. Thus, packages are the unit of
-granularity for deciding whether or not to allow access. If `B` depends on `A`
-but `A` is not visible to `B`, then any attempt to build `B` fails during
-[analysis](/reference/glossary#analysis-phase).
-
-Note that granting visibility to a package does not by itself grant visibility
-to its subpackages. For more details on package and subpackages, see
-[Concepts and terminology](/concepts/build-ref).
-
-For prototyping, you can disable target visibility enforcement by setting the
-flag `--check_visibility=false`. This should not be done for production usage in
-submitted code.
-
-The primary way to control visibility is with the
-[`visibility`](/reference/be/common-definitions#common.visibility) attribute on
-rule targets. This section describes the format of this attribute, and how to
-determine a target's visibility.
-
-### Visibility specifications
-
-All rule targets have a `visibility` attribute that takes a list of labels. Each
-label has one of the following forms. With the exception of the last form, these
-are just syntactic placeholders that do not correspond to any actual target.
-
-* `"//visibility:public"`: Grants access to all packages. (May not be combined
- with any other specification.)
-
-* `"//visibility:private"`: Does not grant any additional access; only targets
- in this package can use this target. (May not be combined with any other
- specification.)
-
-* `"//foo/bar:__pkg__"`: Grants access to `//foo/bar` (but not its
- subpackages).
-
-* `"//foo/bar:__subpackages__"`: Grants access `//foo/bar` and all of its
- direct and indirect subpackages.
-
-* `"//some_pkg:my_package_group"`: Grants access to all of the packages that
- are part of the given [`package_group`](/reference/be/functions#package_group).
-
- * Package groups use a
- [different syntax](/reference/be/functions#package_group.packages) for
- specifying packages. Within a package group, the forms
- `"//foo/bar:__pkg__"` and `"//foo/bar:__subpackages__"` are respectively
- replaced by `"//foo/bar"` and `"//foo/bar/..."`. Likewise,
- `"//visibility:public"` and `"//visibility:private"` are just `"public"`
- and `"private"`.
-
-For example, if `//some/package:mytarget` has its `visibility` set to
-`[":__subpackages__", "//tests:__pkg__"]`, then it could be used by any target
-that is part of the `//some/package/...` source tree, as well as targets defined
-in `//tests/BUILD`, but not by targets defined in `//tests/integration/BUILD`.
-
-**Best practice:** To make several targets visible to the same set
-of packages, use a `package_group` instead of repeating the list in each
-target's `visibility` attribute. This increases readability and prevents the
-lists from getting out of sync.
-
-Note: The `visibility` attribute may not specify non-`package_group` targets.
-Doing so triggers a "Label does not refer to a package group" or "Cycle in
-dependency graph" error.
-
-### Rule target visibility
-
-A rule target's visibility is:
-
-1. The value of its `visibility` attribute, if set; or else
-
-2. The value of the
-[`default_visibility`](/reference/be/functions#package.default_visibility)
-argument of the [`package`](/reference/be/functions#package) statement in the
-target's `BUILD` file, if such a declaration exists; or else
-
-3. `//visibility:private`.
-
-**Best practice:** Avoid setting `default_visibility` to public. It may be
-convenient for prototyping or in small codebases, but the risk of inadvertently
-creating public targets increases as the codebase grows. It's better to be
-explicit about which targets are part of a package's public interface.
-
-#### Example
-
-File `//frobber/bin/BUILD`:
-
-```python
-# This target is visible to everyone
-cc_binary(
- name = "executable",
- visibility = ["//visibility:public"],
- deps = [":library"],
-)
-
-# This target is visible only to targets declared in the same package
-cc_library(
- name = "library",
- # No visibility -- defaults to private since no
- # package(default_visibility = ...) was used.
-)
-
-# This target is visible to targets in package //object and //noun
-cc_library(
- name = "subject",
- visibility = [
- "//noun:__pkg__",
- "//object:__pkg__",
- ],
-)
-
-# See package group "//frobber:friends" (below) for who can
-# access this target.
-cc_library(
- name = "thingy",
- visibility = ["//frobber:friends"],
-)
-```
-
-File `//frobber/BUILD`:
-
-```python
-# This is the package group declaration to which target
-# //frobber/bin:thingy refers.
-#
-# Our friends are packages //frobber, //fribber and any
-# subpackage of //fribber.
-package_group(
- name = "friends",
- packages = [
- "//fribber/...",
- "//frobber",
- ],
-)
-```
-
-### Generated file target visibility
-
-A generated file target has the same visibility as the rule target that
-generates it.
-
-### Source file target visibility
-
-You can explicitly set the visibility of a source file target by calling
-[`exports_files`](/reference/be/functions#exports_files). When no `visibility`
-argument is passed to `exports_files`, it makes the visibility public.
-`exports_files` may not be used to override the visibility of a generated file.
-
-For source file targets that do not appear in a call to `exports_files`, the
-visibility depends on the value of the flag
-[`--incompatible_no_implicit_file_export`](https://github.com/bazelbuild/bazel/issues/10225):
-
-* If the flag is set, the visibility is private.
-
-* Else, the legacy behavior applies: The visibility is the same as the
- `BUILD` file's `default_visibility`, or private if a default visibility is
- not specified.
-
-Avoid relying on the legacy behavior. Always write an `exports_files`
-declaration whenever a source file target needs non-private visibility.
-
-**Best practice:** When possible, prefer to expose a rule target rather than a
-source file. For example, instead of calling `exports_files` on a `.java` file,
-wrap the file in a non-private `java_library` target. Generally, rule targets
-should only directly reference source files that live in the same package.
-
-#### Example
-
-File `//frobber/data/BUILD`:
-
-```python
-exports_files(["readme.txt"])
-```
-
-File `//frobber/bin/BUILD`:
-
-```python
-cc_binary(
- name = "my-program",
- data = ["//frobber/data:readme.txt"],
-)
-```
-
-### Config setting visibility
-
-Historically, Bazel has not enforced visibility for
-[`config_setting`](/reference/be/general#config_setting) targets that are
-referenced in the keys of a [`select()`](/reference/be/functions#select). There
-are two flags to remove this legacy behavior:
-
-* [`--incompatible_enforce_config_setting_visibility`](https://github.com/bazelbuild/bazel/issues/12932)
- enables visibility checking for these targets. To assist with migration, it
- also causes any `config_setting` that does not specify a `visibility` to be
- considered public (regardless of package-level `default_visibility`).
-
-* [`--incompatible_config_setting_private_default_visibility`](https://github.com/bazelbuild/bazel/issues/12933)
- causes `config_setting`s that do not specify a `visibility` to respect the
- package's `default_visibility` and to fallback on private visibility, just
- like any other rule target. It is a no-op if
- `--incompatible_enforce_config_setting_visibility` is not set.
-
-Avoid relying on the legacy behavior. Any `config_setting` that is intended to
-be used outside the current package should have an explicit `visibility`, if the
-package does not already specify a suitable `default_visibility`.
-
-### Package group target visibility
-
-`package_group` targets do not have a `visibility` attribute. They are always
-publicly visible.
-
-### Visibility of implicit dependencies
-
-Some rules have [implicit dependencies](/extending/rules#private_attributes_and_implicit_dependencies) —
-dependencies that are not spelled out in a `BUILD` file but are inherent to
-every instance of that rule. For example, a `cc_library` rule might create an
-implicit dependency from each of its rule targets to an executable target
-representing a C++ compiler.
-
-The visibility of such an implicit dependency is checked with respect to the
-package containing the `.bzl` file in which the rule (or aspect) is defined. In
-our example, the C++ compiler could be private so long as it lives in the same
-package as the definition of the `cc_library` rule. As a fallback, if the
-implicit dependency is not visible from the definition, it is checked with
-respect to the `cc_library` target.
-
-You can change this behavior by disabling
-[`--incompatible_visibility_private_attributes_at_definition`](https://github.com/bazelbuild/proposals/blob/master/designs/2019-10-15-tool-visibility.md).
-When disabled, implicit dependencies are treated like any other dependency.
-This means that the target being depended on (such as our C++ compiler) must be
-visible to every instance of the rule. In practice this usually means the target
-must have public visibility.
-
-If you want to restrict the usage of a rule to certain packages, use
-[load visibility](#load-visibility) instead.
-
-## Load visibility
-
-**Load visibility** controls whether a `.bzl` file may be loaded from other
-`BUILD` or `.bzl` files.
-
-In the same way that target visibility protects source code that is encapsulated
-by targets, load visibility protects build logic that is encapsulated by `.bzl`
-files. For instance, a `BUILD` file author might wish to factor some repetitive
-target definitions into a macro in a `.bzl` file. Without the protection of load
-visibility, they might find their macro reused by other collaborators in the
-same workspace, so that modifying the macro breaks other teams' builds.
-
-Note that a `.bzl` file may or may not have a corresponding source file target.
-If it does, there is no guarantee that the load visibility and the target
-visibility coincide. That is, the same `BUILD` file might be able to load the
-`.bzl` file but not list it in the `srcs` of a [`filegroup`](/reference/be/general#filegroup),
-or vice versa. This can sometimes cause problems for rules that wish to consume
-`.bzl` files as source code, such as for documentation generation or testing.
-
-For prototyping, you may disable load visibility enforcement by setting
-`--check_bzl_visibility=false`. As with `--check_visibility=false`, this should
-not be done for submitted code.
-
-Load visibility is available as of Bazel 6.0.
-
-### Declaring load visibility
-
-To set the load visibility of a `.bzl` file, call the
-[`visibility()`](/rules/lib/globals#visibility) function from within the file.
-The argument to `visibility()` is a list of package specifications, just like
-the [`packages`](/reference/be/functions#package_group.packages) attribute of
-`package_group`. However, `visibility()` does not accept negative package
-specifications.
-
-The call to `visibility()` must only occur once per file, at the top level (not
-inside a function), and ideally immediately following the `load()` statements.
-
-Unlike target visibility, the default load visibility is always public. Files
-that do not call `visibility()` are always loadable from anywhere in the
-workspace. It is a good idea to add `visibility("private")` to the top of any
-new `.bzl` file that is not specifically intended for use outside the package.
-
-### Example
-
-```python
-# //mylib/internal_defs.bzl
-
-# Available to subpackages and to mylib's tests.
-visibility(["//mylib/...", "//tests/mylib/..."])
-
-def helper(...):
- ...
-```
-
-```python
-# //mylib/rules.bzl
-
-load(":internal_defs.bzl", "helper")
-# Set visibility explicitly, even though public is the default.
-# Note the [] can be omitted when there's only one entry.
-visibility("public")
-
-myrule = rule(
- ...
-)
-```
-
-```python
-# //someclient/BUILD
-
-load("//mylib:rules.bzl", "myrule") # ok
-load("//mylib:internal_defs.bzl", "helper") # error
-
-...
-```
-
-### Load visibility practices
-
-This section describes tips for managing load visibility declarations.
-
-#### Factoring visibilities
-
-When multiple `.bzl` files should have the same visibility, it can be helpful to
-factor their package specifications into a common list. For example:
-
-```python
-# //mylib/internal_defs.bzl
-
-visibility("private")
-
-clients = [
- "//foo",
- "//bar/baz/...",
- ...
-]
-```
-
-```python
-# //mylib/feature_A.bzl
-
-load(":internal_defs.bzl", "clients")
-visibility(clients)
-
-...
-```
-
-```python
-# //mylib/feature_B.bzl
-
-load(":internal_defs.bzl", "clients")
-visibility(clients)
-
-...
-```
-
-This helps prevent accidental skew between the various `.bzl` files'
-visibilities. It also is more readable when the `clients` list is large.
-
-#### Composing visibilities
-
-Sometimes a `.bzl` file might need to be visible to an allowlist that is
-composed of multiple smaller allowlists. This is analogous to how a
-`package_group` can incorporate other `package_group`s via its
-[`includes`](/reference/be/functions#package_group.includes) attribute.
-
-Suppose you are deprecating a widely used macro. You want it to be visible only
-to existing users and to the packages owned by your own team. You might write:
-
-```python
-# //mylib/macros.bzl
-
-load(":internal_defs.bzl", "our_packages")
-load("//some_big_client:defs.bzl", "their_remaining_uses)
-
-# List concatenation. Duplicates are fine.
-visibility(our_packages + their_remaining_uses)
-```
-
-#### Deduplicating with package groups
-
-Unlike target visibility, you cannot define a load visibility in terms of a
-`package_group`. If you want to reuse the same allowlist for both target
-visibility and load visibility, it's best to move the list of package
-specifications into a .bzl file, where both kinds of declarations may refer to
-it. Building off the example in [Factoring visibilities](#factoring-visibilities)
-above, you might write:
-
-```python
-# //mylib/BUILD
-
-load(":internal_defs", "clients")
-
-package_group(
- name = "my_pkg_grp",
- packages = clients,
-)
-```
-
-This only works if the list does not contain any negative package
-specifications.
-
-#### Protecting individual symbols
-
-Any Starlark symbol whose name begins with an underscore cannot be loaded from
-another file. This makes it easy to create private symbols, but does not allow
-you to share these symbols with a limited set of trusted files. On the other
-hand, load visibility gives you control over what other packages may see your
-`.bzl file`, but does not allow you to prevent any non-underscored symbol from
-being loaded.
-
-Luckily, you can combine these two features to get fine-grained control.
-
-```python
-# //mylib/internal_defs.bzl
-
-# Can't be public, because internal_helper shouldn't be exposed to the world.
-visibility("private")
-
-# Can't be underscore-prefixed, because this is
-# needed by other .bzl files in mylib.
-def internal_helper(...):
- ...
-
-def public_util(...):
- ...
-```
-
-```python
-# //mylib/defs.bzl
-
-load(":internal_defs", "internal_helper", _public_util="public_util")
-visibility("public")
-
-# internal_helper, as a loaded symbol, is available for use in this file but
-# can't be imported by clients who load this file.
-...
-
-# Re-export public_util from this file by assigning it to a global variable.
-# We needed to import it under a different name ("_public_util") in order for
-# this assignment to be legal.
-public_util = _public_util
-```
-
-#### bzl-visibility Buildifier lint
-
-There is a [Buildifier lint](https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#bzl-visibility)
-that provides a warning if users load a file from a directory named `internal`
-or `private`, when the user's file is not itself underneath the parent of that
-directory. This lint predates the load visibility feature and is unnecessary in
-workspaces where `.bzl` files declare visibilities.
diff --git a/6.5.0/configure/attributes.mdx b/6.5.0/configure/attributes.mdx
deleted file mode 100644
index 86e7117..0000000
--- a/6.5.0/configure/attributes.mdx
+++ /dev/null
@@ -1,1093 +0,0 @@
----
-title: 'Configurable Build Attributes'
----
-
-
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
-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
-feature-configurable binary that can be customized at build time.
-
-## Example
-
-```python
-# myapp/BUILD
-
-cc_binary(
- name = "mybinary",
- srcs = ["main.cc"],
- deps = select({
- ":arm_build": [":arm_lib"],
- ":x86_debug_build": [":x86_dev_lib"],
- "//conditions:default": [":generic_lib"],
- }),
-)
-
-config_setting(
- name = "arm_build",
- values = {"cpu": "arm"},
-)
-
-config_setting(
- name = "x86_debug_build",
- values = {
- "cpu": "x86",
- "compilation_mode": "dbg",
- },
-)
-```
-
-This declares a `cc_binary` that "chooses" its deps based on the flags at the
-command line. Specifically, `deps` becomes:
-
-| Command | -deps = | -
bazel build //myapp:mybinary --cpu=arm |
- [":arm_lib"] |
-
bazel build //myapp:mybinary -c dbg --cpu=x86 |
- [":x86_dev_lib"] |
-
bazel build //myapp:mybinary --cpu=ppc |
- [":generic_lib"] |
-
bazel build //myapp:mybinary -c dbg --cpu=ppc |
- [":generic_lib"] |
-
| Command | -deps = | -
bazel build //myapp:mybinary --cpu=arm |
- [":arm_lib"] |
-
bazel build //myapp:mybinary -c dbg --cpu=x86 |
- [":x86_dev_lib"] |
-
bazel build //myapp:mybinary --cpu=ppc |
- [":generic_lib"] |
-
bazel build //myapp:mybinary -c dbg --cpu=ppc |
- [":generic_lib"] |
-
-
-This works, because Bazel will always run the validation action when the compile
-action is run, but this has significant drawbacks:
-
-1. The validation action is in the critical path of the build. Because Bazel
-thinks the empty output is required to run the compile action, it will run the
-validation action first, even though the compile action will ignore the input.
-This reduces parallelism and slows down builds.
-
-2. If other actions in the build might run instead of the
-compile action, then the empty outputs of validation actions need to be added to
-those actions as well (`java_library`'s source jar output, for example). This is
-also a problem if new actions that might run instead of the compile action are
-added later, and the empty validation output is accidentally left off.
-
-The solution to these problems is to use the Validations Output Group.
-
-#### Validations Output Group
-
-The Validations Output Group is an output group designed to hold the otherwise
-unused outputs of validation actions, so that they don't need to be artificially
-added to the inputs of other actions.
-
-This group is special in that its outputs are always requested, regardless of
-the value of the `--output_groups` flag, and regardless of how the target is
-depended upon (for example, on the command line, as a dependency, or through
-implicit outputs of the target). Note that normal caching and incrementality
-still apply: if the inputs to the validation action have not changed and the
-validation action previously succeeded, then the validation action will not be
-run.
-
-
-
-Using this output group still requires that validation actions output some file,
-even an empty one. This might require wrapping some tools that normally don't
-create outputs so that a file is created.
-
-A target's validation actions are not run in three cases:
-
-* When the target is depended upon as a tool
-* When the target is depended upon as an implicit dependency (for example, an
- attribute that starts with "_")
-* When the target is built in the host or exec configuration.
-
-It is assumed that these targets have their own
-separate builds and tests that would uncover any validation failures.
-
-#### Using the Validations Output Group
-
-The Validations Output Group is named `_validation` and is used like any other
-output group:
-
-```python
-def _rule_with_validation_impl(ctx):
-
- ctx.actions.write(ctx.outputs.main, "main output\n")
-
- ctx.actions.write(ctx.outputs.implicit, "implicit output\n")
-
- validation_output = ctx.actions.declare_file(ctx.attr.name + ".validation")
- ctx.actions.run(
- outputs = [validation_output],
- executable = ctx.executable._validation_tool,
- arguments = [validation_output.path])
-
- return [
- DefaultInfo(files = depset([ctx.outputs.main])),
- OutputGroupInfo(_validation = depset([validation_output])),
- ]
-
-
-rule_with_validation = rule(
- implementation = _rule_with_validation_impl,
- outputs = {
- "main": "%{name}.main",
- "implicit": "%{name}.implicit",
- },
- attrs = {
- "_validation_tool": attr.label(
- default = Label("//validation_actions:validation_tool"),
- executable = True,
- cfg = "exec"),
- }
-)
-```
-
-Notice that the validation output file is not added to the `DefaultInfo` or the
-inputs to any other action. The validation action for a target of this rule kind
-will still run if the target is depended upon by label, or any of the target's
-implicit outputs are directly or indirectly depended upon.
-
-It is usually important that the outputs of validation actions only go into the
-validation output group, and are not added to the inputs of other actions, as
-this could defeat parallelism gains. Note however that Bazel does not currently
-have any special checking to enforce this. Therefore, you should test
-that validation action outputs are not added to the inputs of any actions in the
-tests for Starlark rules. For example:
-
-```python
-load("@bazel_skylib//lib:unittest.bzl", "analysistest")
-
-def _validation_outputs_test_impl(ctx):
- env = analysistest.begin(ctx)
-
- actions = analysistest.target_actions(env)
- target = analysistest.target_under_test(env)
- validation_outputs = target.output_groups._validation.to_list()
- for action in actions:
- for validation_output in validation_outputs:
- if validation_output in action.inputs.to_list():
- analysistest.fail(env,
- "%s is a validation action output, but is an input to action %s" % (
- validation_output, action))
-
- return analysistest.end(env)
-
-validation_outputs_test = analysistest.make(_validation_outputs_test_impl)
-```
-
-#### Validation Actions Flag
-
-Running validation actions is controlled by the `--run_validations` command line
-flag, which defaults to true.
-
-## Deprecated features
-
-### Deprecated predeclared outputs
-
-There are two **deprecated** ways of using predeclared outputs:
-
-* The [`outputs`](/rules/lib/globals#rule.outputs) parameter of `rule` specifies
- a mapping between output attribute names and string templates for generating
- predeclared output labels. Prefer using non-predeclared outputs and
- explicitly adding outputs to `DefaultInfo.files`. Use the rule target's
- label as input for rules which consume the output instead of a predeclared
- output's label.
-
-* For [executable rules](#executable-rules), `ctx.outputs.executable` refers
- to a predeclared executable output with the same name as the rule target.
- Prefer declaring the output explicitly, for example with
- `ctx.actions.declare_file(ctx.label.name)`, and ensure that the command that
- generates the executable sets its permissions to allow execution. Explicitly
- pass the executable output to the `executable` parameter of `DefaultInfo`.
-
-### Runfiles features to avoid
-
-[`ctx.runfiles`](/rules/lib/ctx#runfiles) and the [`runfiles`](/rules/lib/runfiles)
-type have a complex set of features, many of which are kept for legacy reasons.
-The following recommendations help reduce complexity:
-
-* **Avoid** use of the `collect_data` and `collect_default` modes of
- [`ctx.runfiles`](/rules/lib/ctx#runfiles). These modes implicitly collect
- runfiles across certain hardcoded dependency edges in confusing ways.
- Instead, add files using the `files` or `transitive_files` parameters of
- `ctx.runfiles`, or by merging in runfiles from dependencies with
- `runfiles = runfiles.merge(dep[DefaultInfo].default_runfiles)`.
-
-* **Avoid** use of the `data_runfiles` and `default_runfiles` of the
- `DefaultInfo` constructor. Specify `DefaultInfo(runfiles = ...)` instead.
- The distinction between "default" and "data" runfiles is maintained for
- legacy reasons. For example, some rules put their default outputs in
- `data_runfiles`, but not `default_runfiles`. Instead of using
- `data_runfiles`, rules should *both* include default outputs and merge in
- `default_runfiles` from attributes which provide runfiles (often
- [`data`](/reference/be/common-definitions#common-attributes.data)).
-
-* When retrieving `runfiles` from `DefaultInfo` (generally only for merging
- runfiles between the current rule and its dependencies), use
- `DefaultInfo.default_runfiles`, **not** `DefaultInfo.data_runfiles`.
-
-### Migrating from legacy providers
-
-Historically, Bazel providers were simple fields on the `Target` object. They
-were accessed using the dot operator, and they were created by putting the field
-in a struct returned by the rule's implementation function.
-
-*This style is deprecated and should not be used in new code;* see below for
-information that may help you migrate. The new provider mechanism avoids name
-clashes. It also supports data hiding, by requiring any code accessing a
-provider instance to retrieve it using the provider symbol.
-
-For the moment, legacy providers are still supported. A rule can return both
-legacy and modern providers as follows:
-
-```python
-def _old_rule_impl(ctx):
- ...
- legacy_data = struct(x="foo", ...)
- modern_data = MyInfo(y="bar", ...)
- # When any legacy providers are returned, the top-level returned value is a
- # struct.
- return struct(
- # One key = value entry for each legacy provider.
- legacy_info = legacy_data,
- ...
- # Additional modern providers:
- providers = [modern_data, ...])
-```
-
-If `dep` is the resulting `Target` object for an instance of this rule, the
-providers and their contents can be retrieved as `dep.legacy_info.x` and
-`dep[MyInfo].y`.
-
-In addition to `providers`, the returned struct can also take several other
-fields that have special meaning (and thus do not create a corresponding legacy
-provider):
-
-* The fields `files`, `runfiles`, `data_runfiles`, `default_runfiles`, and
- `executable` correspond to the same-named fields of
- [`DefaultInfo`](/rules/lib/DefaultInfo). It is not allowed to specify any of
- these fields while also returning a `DefaultInfo` provider.
-
-* The field `output_groups` takes a struct value and corresponds to an
- [`OutputGroupInfo`](/rules/lib/OutputGroupInfo).
-
-In [`provides`](/rules/lib/globals#rule.provides) declarations of rules, and in
-[`providers`](/rules/lib/attr#label_list.providers) declarations of dependency
-attributes, legacy providers are passed in as strings and modern providers are
-passed in by their `*Info` symbol. Be sure to change from strings to symbols
-when migrating. For complex or large rule sets where it is difficult to update
-all rules atomically, you may have an easier time if you follow this sequence of
-steps:
-
-1. Modify the rules that produce the legacy provider to produce both the legacy
- and modern providers, using the above syntax. For rules that declare they
- return the legacy provider, update that declaration to include both the
- legacy and modern providers.
-
-2. Modify the rules that consume the legacy provider to instead consume the
- modern provider. If any attribute declarations require the legacy provider,
- also update them to instead require the modern provider. Optionally, you can
- interleave this work with step 1 by having consumers accept/require either
- provider: Test for the presence of the legacy provider using
- `hasattr(target, 'foo')`, or the new provider using `FooInfo in target`.
-
-3. Fully remove the legacy provider from all rules.
diff --git a/6.5.0/extending/toolchains.mdx b/6.5.0/extending/toolchains.mdx
deleted file mode 100644
index 8b19fbc..0000000
--- a/6.5.0/extending/toolchains.mdx
+++ /dev/null
@@ -1,564 +0,0 @@
----
-title: 'Toolchains'
----
-
-
-This page describes the toolchain framework, which is a way for rule authors to
-decouple their rule logic from platform-based selection of tools. It is
-recommended to read the [rules](/rules/rules) and [platforms](/docs/platforms)
-pages before continuing. This page covers why toolchains are needed, how to
-define and use them, and how Bazel selects an appropriate toolchain based on
-platform constraints.
-
-## Motivation
-
-Let's first look at the problem toolchains are designed to solve. Suppose you
-are writing rules to support the "bar" programming language. Your `bar_binary`
-rule would compile `*.bar` files using the `barc` compiler, a tool that itself
-is built as another target in your workspace. Since users who write `bar_binary`
-targets shouldn't have to specify a dependency on the compiler, you make it an
-implicit dependency by adding it to the rule definition as a private attribute.
-
-```python
-bar_binary = rule(
- implementation = _bar_binary_impl,
- attrs = {
- "srcs": attr.label_list(allow_files = True),
- ...
- "_compiler": attr.label(
- default = "//bar_tools:barc_linux", # the compiler running on linux
- providers = [BarcInfo],
- ),
- },
-)
-```
-
-`//bar_tools:barc_linux` is now a dependency of every `bar_binary` target, so
-it'll be built before any `bar_binary` target. It can be accessed by the rule's
-implementation function just like any other attribute:
-
-```python
-BarcInfo = provider(
- doc = "Information about how to invoke the barc compiler.",
- # In the real world, compiler_path and system_lib might hold File objects,
- # but for simplicity they are strings for this example. arch_flags is a list
- # of strings.
- fields = ["compiler_path", "system_lib", "arch_flags"],
-)
-
-def _bar_binary_impl(ctx):
- ...
- info = ctx.attr._compiler[BarcInfo]
- command = "%s -l %s %s" % (
- info.compiler_path,
- info.system_lib,
- " ".join(info.arch_flags),
- )
- ...
-```
-
-The issue here is that the compiler's label is hardcoded into `bar_binary`, yet
-different targets may need different compilers depending on what platform they
-are being built for and what platform they are being built on -- called the
-*target platform* and *execution platform*, respectively. Furthermore, the rule
-author does not necessarily even know all the available tools and platforms, so
-it is not feasible to hardcode them in the rule's definition.
-
-A less-than-ideal solution would be to shift the burden onto users, by making
-the `_compiler` attribute non-private. Then individual targets could be
-hardcoded to build for one platform or another.
-
-```python
-bar_binary(
- name = "myprog_on_linux",
- srcs = ["mysrc.bar"],
- compiler = "//bar_tools:barc_linux",
-)
-
-bar_binary(
- name = "myprog_on_windows",
- srcs = ["mysrc.bar"],
- compiler = "//bar_tools:barc_windows",
-)
-```
-
-You can improve on this solution by using `select` to choose the `compiler`
-[based on the platform](/docs/configurable-attributes):
-
-```python
-config_setting(
- name = "on_linux",
- constraint_values = [
- "@platforms//os:linux",
- ],
-)
-
-config_setting(
- name = "on_windows",
- constraint_values = [
- "@platforms//os:windows",
- ],
-)
-
-bar_binary(
- name = "myprog",
- srcs = ["mysrc.bar"],
- compiler = select({
- ":on_linux": "//bar_tools:barc_linux",
- ":on_windows": "//bar_tools:barc_windows",
- }),
-)
-```
-
-But this is tedious and a bit much to ask of every single `bar_binary` user.
-If this style is not used consistently throughout the workspace, it leads to
-builds that work fine on a single platform but fail when extended to
-multi-platform scenarios. It also does not address the problem of adding support
-for new platforms and compilers without modifying existing rules or targets.
-
-The toolchain framework solves this problem by adding an extra level of
-indirection. Essentially, you declare that your rule has an abstract dependency
-on *some* member of a family of targets (a toolchain type), and Bazel
-automatically resolves this to a particular target (a toolchain) based on the
-applicable platform constraints. Neither the rule author nor the target author
-need know the complete set of available platforms and toolchains.
-
-## Writing rules that use toolchains
-
-Under the toolchain framework, instead of having rules depend directly on tools,
-they instead depend on *toolchain types*. A toolchain type is a simple target
-that represents a class of tools that serve the same role for different
-platforms. For instance, you can declare a type that represents the bar
-compiler:
-
-```python
-# By convention, toolchain_type targets are named "toolchain_type" and
-# distinguished by their package path. So the full path for this would be
-# //bar_tools:toolchain_type.
-toolchain_type(name = "toolchain_type")
-```
-
-The rule definition in the previous section is modified so that instead of
-taking in the compiler as an attribute, it declares that it consumes a
-`//bar_tools:toolchain_type` toolchain.
-
-```python
-bar_binary = rule(
- implementation = _bar_binary_impl,
- attrs = {
- "srcs": attr.label_list(allow_files = True),
- ...
- # No `_compiler` attribute anymore.
- },
- toolchains = ["//bar_tools:toolchain_type"],
-)
-```
-
-The implementation function now accesses this dependency under `ctx.toolchains`
-instead of `ctx.attr`, using the toolchain type as the key.
-
-```python
-def _bar_binary_impl(ctx):
- ...
- info = ctx.toolchains["//bar_tools:toolchain_type"].barcinfo
- # The rest is unchanged.
- command = "%s -l %s %s" % (
- info.compiler_path,
- info.system_lib,
- " ".join(info.arch_flags),
- )
- ...
-```
-
-`ctx.toolchains["//bar_tools:toolchain_type"]` returns the
-[`ToolchainInfo` provider](/rules/lib/platform_common#ToolchainInfo)
-of whatever target Bazel resolved the toolchain dependency to. The fields of the
-`ToolchainInfo` object are set by the underlying tool's rule; in the next
-section, this rule is defined such that there is a `barcinfo` field that wraps
-a `BarcInfo` object.
-
-Bazel's procedure for resolving toolchains to targets is described
-[below](#toolchain-resolution). Only the resolved toolchain target is actually
-made a dependency of the `bar_binary` target, not the whole space of candidate
-toolchains.
-
-### Mandatory and Optional Toolchains
-
-By default, when a rule expresses a toolchain type dependency using a bare label
-(as shown above), the toolchain type is considered to be **mandatory**. If Bazel
-is unable to find a matching toolchain (see
-[Toolchain resolution](#toolchain-resolution) below) for a mandatory toolchain
-type, this is an error and analysis halts.
-
-It is possible instead to declare an **optional** toolchain type dependency, as
-follows:
-
-```python
-bar_binary = rule(
- ...
- toolchains = [
- config_common.toolchain_type("//bar_tools:toolchain_type", mandatory = False),
- ],
-)
-```
-
-When an optional toolchain type cannot be resolved, analysis continues, and the
-result of `ctx.toolchains[""//bar_tools:toolchain_type"]` is `None`.
-
-The [`config_common.toolchain_type`](/rules/lib/config_common#toolchain_type)
-function defaults to mandatory.
-
-The following forms can be used:
-
-- Mandatory toolchain types:
- - `toolchains = ["//bar_tools:toolchain_type"]`
- - `toolchains = [config_common.toolchain_type("//bar_tools:toolchain_type")]`
- - `toolchains = [config_common.toolchain_type("//bar_tools:toolchain_type", mandatory = True)]`
-- Optional toolchain types:
- - `toolchains = [config_common.toolchain_type("//bar_tools:toolchain_type", mandatory = False)]`
-
-```python
-bar_binary = rule(
- ...
- toolchains = [
- "//foo_tools:toolchain_type",
- config_common.toolchain_type("//bar_tools:toolchain_type", mandatory = False),
- ],
-)
-```
-
-You can mix and match forms in the same rule, also. However, if the same
-toolchain type is listed multiple times, it will take the most strict version,
-where mandatory is more strict than optional.
-
-### Writing aspects that use toolchains
-
-Aspects have access to the same toolchain API as rules: you can define required
-toolchain types, access toolchains via the context, and use them to generate new
-actions using the toolchain.
-
-```py
-bar_aspect = aspect(
- implementation = _bar_aspect_impl,
- attrs = {},
- toolchains = ['//bar_tools:toolchain_type'],
-)
-
-def _bar_aspect_impl(target, ctx):
- toolchain = ctx.toolchains['//bar_tools:toolchain_type']
- # Use the toolchain provider like in a rule.
- return []
-```
-
-## Defining toolchains
-
-To define some toolchains for a given toolchain type, you need three things:
-
-1. A language-specific rule representing the kind of tool or tool suite. By
- convention this rule's name is suffixed with "\_toolchain".
-
- 1. **Note:** The `\_toolchain` rule cannot create any build actions.
- Rather, it collects artifacts from other rules and forwards them to the
- rule that uses the toolchain. That rule is responsible for creating all
- build actions.
-
-2. Several targets of this rule type, representing versions of the tool or tool
- suite for different platforms.
-
-3. For each such target, an associated target of the generic
- [`toolchain`](/reference/be/platform#toolchain)
- rule, to provide metadata used by the toolchain framework. This `toolchain`
- target also refers to the `toolchain_type` associated with this toolchain.
- This means that a given `_toolchain` rule could be associated with any
- `toolchain_type`, and that only in a `toolchain` instance that uses
- this `_toolchain` rule that the rule is associated with a `toolchain_type`.
-
-For our running example, here's a definition for a `bar_toolchain` rule. Our
-example has only a compiler, but other tools such as a linker could also be
-grouped underneath it.
-
-```python
-def _bar_toolchain_impl(ctx):
- toolchain_info = platform_common.ToolchainInfo(
- barcinfo = BarcInfo(
- compiler_path = ctx.attr.compiler_path,
- system_lib = ctx.attr.system_lib,
- arch_flags = ctx.attr.arch_flags,
- ),
- )
- return [toolchain_info]
-
-bar_toolchain = rule(
- implementation = _bar_toolchain_impl,
- attrs = {
- "compiler_path": attr.string(),
- "system_lib": attr.string(),
- "arch_flags": attr.string_list(),
- },
-)
-```
-
-The rule must return a `ToolchainInfo` provider, which becomes the object that
-the consuming rule retrieves using `ctx.toolchains` and the label of the
-toolchain type. `ToolchainInfo`, like `struct`, can hold arbitrary field-value
-pairs. The specification of exactly what fields are added to the `ToolchainInfo`
-should be clearly documented at the toolchain type. In this example, the values
-return wrapped in a `BarcInfo` object to reuse the schema defined above; this
-style may be useful for validation and code reuse.
-
-Now you can define targets for specific `barc` compilers.
-
-```python
-bar_toolchain(
- name = "barc_linux",
- arch_flags = [
- "--arch=Linux",
- "--debug_everything",
- ],
- compiler_path = "/path/to/barc/on/linux",
- system_lib = "/usr/lib/libbarc.so",
-)
-
-bar_toolchain(
- name = "barc_windows",
- arch_flags = [
- "--arch=Windows",
- # Different flags, no debug support on windows.
- ],
- compiler_path = "C:\\path\\on\\windows\\barc.exe",
- system_lib = "C:\\path\\on\\windows\\barclib.dll",
-)
-```
-
-Finally, you create `toolchain` definitions for the two `bar_toolchain` targets.
-These definitions link the language-specific targets to the toolchain type and
-provide the constraint information that tells Bazel when the toolchain is
-appropriate for a given platform.
-
-```python
-toolchain(
- name = "barc_linux_toolchain",
- exec_compatible_with = [
- "@platforms//os:linux",
- "@platforms//cpu:x86_64",
- ],
- target_compatible_with = [
- "@platforms//os:linux",
- "@platforms//cpu:x86_64",
- ],
- toolchain = ":barc_linux",
- toolchain_type = ":toolchain_type",
-)
-
-toolchain(
- name = "barc_windows_toolchain",
- exec_compatible_with = [
- "@platforms//os:windows",
- "@platforms//cpu:x86_64",
- ],
- target_compatible_with = [
- "@platforms//os:windows",
- "@platforms//cpu:x86_64",
- ],
- toolchain = ":barc_windows",
- toolchain_type = ":toolchain_type",
-)
-```
-
-The use of relative path syntax above suggests these definitions are all in the
-same package, but there's no reason the toolchain type, language-specific
-toolchain targets, and `toolchain` definition targets can't all be in separate
-packages.
-
-See the [`go_toolchain`](https://github.com/bazelbuild/rules_go/blob/master/go/private/go_toolchain.bzl)
-for a real-world example.
-
-### Toolchains and configurations
-
-An important question for rule authors is, when a `bar_toolchain` target is
-analyzed, what [configuration](/reference/glossary#configuration) does it see, and what transitions
-should be used for dependencies? The example above uses string attributes, but
-what would happen for a more complicated toolchain that depends on other targets
-in the Bazel repository?
-
-Let's see a more complex version of `bar_toolchain`:
-
-```python
-def _bar_toolchain_impl(ctx):
- # The implementation is mostly the same as above, so skipping.
- pass
-
-bar_toolchain = rule(
- implementation = _bar_toolchain_impl,
- attrs = {
- "compiler": attr.label(
- executable = True,
- mandatory = True,
- cfg = "exec",
- ),
- "system_lib": attr.label(
- mandatory = True,
- cfg = "target",
- ),
- "arch_flags": attr.string_list(),
- },
-)
-```
-
-The use of [`attr.label`](/rules/lib/attr#label) is the same as for a standard rule,
-but the meaning of the `cfg` parameter is slightly different.
-
-The dependency from a target (called the "parent") to a toolchain via toolchain
-resolution uses a special configuration transition called the "toolchain
-transition". The toolchain transition keeps the configuration the same, except
-that it forces the execution platform to be the same for the toolchain as for
-the parent (otherwise, toolchain resolution for the toolchain could pick any
-execution platform, and wouldn't necessarily be the same as for parent). This
-allows any `exec` dependencies of the toolchain to also be executable for the
-parent's build actions. Any of the toolchain's dependencies which use `cfg =
-"target"` (or which don't specify `cfg`, since "target" is the default) are
-built for the same target platform as the parent. This allows toolchain rules to
-contribute both libraries (the `system_lib` attribute above) and tools (the
-`compiler` attribute) to the build rules which need them. The system libraries
-are linked into the final artifact, and so need to be built for the same
-platform, whereas the compiler is a tool invoked during the build, and needs to
-be able to run on the execution platform.
-
-## Registering and building with toolchains
-
-At this point all the building blocks are assembled, and you just need to make
-the toolchains available to Bazel's resolution procedure. This is done by
-registering the toolchain, either in a `WORKSPACE` file using
-`register_toolchains()`, or by passing the toolchains' labels on the command
-line using the `--extra_toolchains` flag.
-
-```python
-register_toolchains(
- "//bar_tools:barc_linux_toolchain",
- "//bar_tools:barc_windows_toolchain",
- # Target patterns are also permitted, so you could have also written:
- # "//bar_tools:all",
-)
-```
-
-Now when you build a target that depends on a toolchain type, an appropriate
-toolchain will be selected based on the target and execution platforms.
-
-```python
-# my_pkg/BUILD
-
-platform(
- name = "my_target_platform",
- constraint_values = [
- "@platforms//os:linux",
- ],
-)
-
-bar_binary(
- name = "my_bar_binary",
- ...
-)
-```
-
-```sh
-bazel build //my_pkg:my_bar_binary --platforms=//my_pkg:my_target_platform
-```
-
-Bazel will see that `//my_pkg:my_bar_binary` is being built with a platform that
-has `@platforms//os:linux` and therefore resolve the
-`//bar_tools:toolchain_type` reference to `//bar_tools:barc_linux_toolchain`.
-This will end up building `//bar_tools:barc_linux` but not
-`//bar_tools:barc_windows`.
-
-## Toolchain resolution
-
-Note: [Some Bazel rules](/concepts/platforms-intro#status) do not yet support
-toolchain resolution.
-
-For each target that uses toolchains, Bazel's toolchain resolution procedure
-determines the target's concrete toolchain dependencies. The procedure takes as input a
-set of required toolchain types, the target platform, the list of available
-execution platforms, and the list of available toolchains. Its outputs are a
-selected toolchain for each toolchain type as well as a selected execution
-platform for the current target.
-
-The available execution platforms and toolchains are gathered from the
-`WORKSPACE` file via
-[`register_execution_platforms`](/rules/lib/globals#register_execution_platforms)
-and
-[`register_toolchains`](/rules/lib/globals#register_toolchains).
-Additional execution platforms and toolchains may also be specified on the
-command line via
-[`--extra_execution_platforms`](/reference/command-line-reference#flag--extra_execution_platforms)
-and
-[`--extra_toolchains`](/reference/command-line-reference#flag--extra_toolchains).
-The host platform is automatically included as an available execution platform.
-Available platforms and toolchains are tracked as ordered lists for determinism,
-with preference given to earlier items in the list.
-
-The resolution steps are as follows.
-
-1. A `target_compatible_with` or `exec_compatible_with` clause *matches* a
- platform if, for each `constraint_value` in its list, the platform also has
- that `constraint_value` (either explicitly or as a default).
-
- If the platform has `constraint_value`s from `constraint_setting`s not
- referenced by the clause, these do not affect matching.
-
-1. If the target being built specifies the
- [`exec_compatible_with` attribute](/reference/be/common-definitions#common.exec_compatible_with)
- (or its rule definition specifies the
- [`exec_compatible_with` argument](/rules/lib/globals#rule.exec_compatible_with)),
- the list of available execution platforms is filtered to remove
- any that do not match the execution constraints.
-
-1. For each available execution platform, you associate each toolchain type with
- the first available toolchain, if any, that is compatible with this execution
- platform and the target platform.
-
-1. Any execution platform that failed to find a compatible mandatory toolchain
- for one of its toolchain types is ruled out. Of the remaining platforms, the
- first one becomes the current target's execution platform, and its associated
- toolchains (if any) become dependencies of the target.
-
-The chosen execution platform is used to run all actions that the target
-generates.
-
-In cases where the same target can be built in multiple configurations (such as
-for different CPUs) within the same build, the resolution procedure is applied
-independently to each version of the target.
-
-If the rule uses [execution groups](/reference/exec-groups), each execution
-group performs toolchain resolution separately, and each has its own execution
-platform and toolchains.
-
-## Debugging toolchains
-
-If you are adding toolchain support to an existing rule, use the
-`--toolchain_resolution_debug=regex` flag. During toolchain resolution, the flag
-provides verbose output for toolchain types or target names that match the regex variable. You
-can use `.*` to output all information. Bazel will output names of toolchains it
-checks and skips during the resolution process.
-
-If you'd like to see which [`cquery`](/docs/cquery) dependencies are from toolchain
-resolution, use `cquery`'s [`--transitions`](/docs/cquery#transitions) flag:
-
-```
-# Find all direct dependencies of //cc:my_cc_lib. This includes explicitly
-# declared dependencies, implicit dependencies, and toolchain dependencies.
-$ bazel cquery 'deps(//cc:my_cc_lib, 1)'
-//cc:my_cc_lib (96d6638)
-@bazel_tools//tools/cpp:toolchain (96d6638)
-@bazel_tools//tools/def_parser:def_parser (HOST)
-//cc:my_cc_dep (96d6638)
-@local_config_platform//:host (96d6638)
-@bazel_tools//tools/cpp:toolchain_type (96d6638)
-//:default_host_platform (96d6638)
-@local_config_cc//:cc-compiler-k8 (HOST)
-//cc:my_cc_lib.cc (null)
-@bazel_tools//tools/cpp:grep-includes (HOST)
-
-# Which of these are from toolchain resolution?
-$ bazel cquery 'deps(//cc:my_cc_lib, 1)' --transitions=lite | grep "toolchain dependency"
- [toolchain dependency]#@local_config_cc//:cc-compiler-k8#HostTransition -> b6df211
-```
diff --git a/6.5.0/external/advanced.mdx b/6.5.0/external/advanced.mdx
deleted file mode 100644
index d468d5d..0000000
--- a/6.5.0/external/advanced.mdx
+++ /dev/null
@@ -1,183 +0,0 @@
----
-title: 'Advanced topics on external dependencies'
----
-
-
-
-## Shadowing dependencies in WORKSPACE
-
-Note: This section applies to the [WORKSPACE
-system](/external/overview#workspace-system) only. For
-[Bzlmod](/external/overview#bzlmod), use a [multiple-version
-override](/external/module#multiple-version_override).
-
-Whenever possible, have a single version policy in your project, which is
-required for dependencies that you compile against and end up in your final
-binary. For other cases, you can shadow dependencies:
-
-myproject/WORKSPACE
-
-```python
-workspace(name = "myproject")
-
-local_repository(
- name = "A",
- path = "../A",
-)
-local_repository(
- name = "B",
- path = "../B",
-)
-```
-
-A/WORKSPACE
-
-```python
-workspace(name = "A")
-
-load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
-http_archive(
- name = "testrunner",
- urls = ["https://github.com/testrunner/v1.zip"],
- sha256 = "...",
-)
-```
-
-B/WORKSPACE {# This is not a buganizer link okay?? #}
-
-```python
-workspace(name = "B")
-
-load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
-http_archive(
- name = "testrunner",
- urls = ["https://github.com/testrunner/v2.zip"],
- sha256 = "..."
-)
-```
-
-Both dependencies `A` and `B` depend on different versions of `testrunner`.
-Include both in `myproject` without conflict by giving them distinct names in
-`myproject/WORKSPACE`:
-
-```python
-workspace(name = "myproject")
-
-load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
-http_archive(
- name = "testrunner-v1",
- urls = ["https://github.com/testrunner/v1.zip"],
- sha256 = "..."
-)
-http_archive(
- name = "testrunner-v2",
- urls = ["https://github.com/testrunner/v2.zip"],
- sha256 = "..."
-)
-local_repository(
- name = "A",
- path = "../A",
- repo_mapping = {"@testrunner" : "@testrunner-v1"}
-)
-local_repository(
- name = "B",
- path = "../B",
- repo_mapping = {"@testrunner" : "@testrunner-v2"}
-)
-```
-
-You can also use this mechanism to join diamonds. For example, if `A` and `B`
-have the same dependency but call it by different names, join those dependencies
-in `myproject/WORKSPACE`.
-
-## Overriding repositories from the command line
-
-To override a declared repository with a local repository from the command line,
-use the
-[`--override_repository`](/reference/command-line-reference#flag--override_repository)
-flag. Using this flag changes the contents of external repositories without
-changing your source code.
-
-For example, to override `@foo` to the local directory `/path/to/local/foo`,
-pass the `--override_repository=foo=/path/to/local/foo` flag.
-
-Use cases include:
-
-* Debugging issues. For example, to override an `http_archive` repository to a
- local directory where you can make changes more easily.
-* Vendoring. If you are in an environment where you cannot make network calls,
- override the network-based repository rules to point to local directories
- instead.
-
-Note: With [Bzlmod](/external/overview#bzlmod), remember to use canonical repo
-names here. Alternatively, use the
-[`--override_module`](/reference/command-line-reference#flag--override_module)
-flag to override a module to a local directory, similar to the
-[`local_path_override`](/rules/lib/globals#local_path_override) directive in
-`MODULE.bazel`.
-
-## Using proxies
-
-Bazel picks up proxy addresses from the `HTTPS_PROXY` and `HTTP_PROXY`
-environment variables and uses these to download `HTTP` and `HTTPS` files (if
-specified).
-
-## Support for IPv6
-
-On IPv6-only machines, Bazel can download dependencies with no changes. However,
-on dual-stack IPv4/IPv6 machines Bazel follows the same convention as Java,
-preferring IPv4 if enabled. In some situations, for example when the IPv4
-network cannot resolve/reach external addresses, this can cause `Network
-unreachable` exceptions and build failures. In these cases, you can override
-Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
-Specifically:
-
-* Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
- option](/docs/user-manual#startup-options), for example by adding the
- following line in your [`.bazelrc` file](/run/bazelrc):
-
- `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
-
-* When running Java build targets that need to connect to the internet (such
- as for integration tests), use the
- `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
- flag](/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
- file](/run/bazelrc):
-
- `build --jvmopt=-Djava.net.preferIPv6Addresses`
-
-* If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
- for dependency version resolution, also add
- `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
- variable to [provide JVM options for
- Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
-
-## Offline builds
-
-Sometimes you may wish to run a build offline, such as when traveling on an
-airplane. For such simple use cases, prefetch the needed repositories with
-`bazel fetch` or `bazel sync`. To disable fetching further repositories during
-the build, use the option `--nofetch`.
-
-For true offline builds, where a different entity supplies all needed files,
-Bazel supports the option `--distdir`. This flag tells Bazel to look first into
-the directories specified by that option when a repository rule asks Bazel to
-fetch a file with [`ctx.download`](/rules/lib/repository_ctx#download) or
-[`ctx.download_and_extract`](/rules/lib/repository_ctx#download_and_extract). By
-providing a hash sum of the file needed, Bazel looks for a file matching the
-basename of the first URL, and uses the local copy if the hash matches.
-
-Bazel itself uses this technique to bootstrap offline from the [distribution
-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)
-in an internal
-[`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
-
-Bazel allows execution of arbitrary commands in repository rules without knowing
-if they call out to the network, and so cannot enforce fully offline builds. To
-test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
diff --git a/6.5.0/external/lockfile.mdx b/6.5.0/external/lockfile.mdx
deleted file mode 100644
index e478bce..0000000
--- a/6.5.0/external/lockfile.mdx
+++ /dev/null
@@ -1,190 +0,0 @@
-keywords: product:Bazel,lockfile,Bzlmod
----
-title: 'Bazel Lockfile'
----
-
-
-
-The lockfile feature in Bazel enables the recording of specific versions or
-dependencies of software libraries or packages required by a project. It
-achieves this by storing the result of module resolution and extension
-evaluation. The lockfile promotes reproducible builds, ensuring consistent
-development environments. Additionally, it enhances build efficiency by allowing
-Bazel to skip the resolution process when there are no changes in project
-dependencies. Furthermore, the lockfile improves stability by preventing
-unexpected updates or breaking changes in external libraries, thereby reducing
-the risk of introducing bugs.
-
-## Lockfile Generation
-
-The lockfile is generated under the workspace root with the name
-`MODULE.bazel.lock`. It is created or updated during the build process,
-specifically after module resolution and extension evaluation. The lockfile
-captures the current state of the project, including the MODULE file, flags,
-overrides, and other relevant information. Importantly, it only includes
-dependencies that are included in the current invocation of the build.
-
-When changes occur in the project that affect its dependencies, the lockfile is
-automatically updated to reflect the new state. This ensures that the lockfile
-remains focused on the specific set of dependencies required for the current
-build, providing an accurate representation of the project's resolved
-dependencies.
-
-## Lockfile Usage
-
-The lockfile can be controlled by the flag
-[`--lockfile_mode`](/reference/command-line-reference#flag--lockfile_mode) to
-customize the behavior of Bazel when the project state differs from the
-lockfile. The available modes are:
-
-* `update` (Default): If the project state matches the lockfile, the
- resolution result is immediately returned from the lockfile. Otherwise,
- resolution is executed, and the lockfile is updated to reflect the current
- state.
-* `error`: If the project state matches the lockfile, the resolution result is
- returned from the lockfile. Otherwise, Bazel throws an error indicating the
- variations between the project and the lockfile. This mode is particularly
- useful when you want to ensure that your project's dependencies remain
- unchanged, and any differences are treated as errors.
-* `off`: The lockfile is not checked at all.
-
-## Lockfile Benefits
-
-The lockfile offers several benefits and can be utilized in various ways:
-
-- **Reproducible builds.** By capturing the specific versions or dependencies
- of software libraries, the lockfile ensures that builds are reproducible
- across different environments and over time. Developers can rely on
- consistent and predictable results when building their projects.
-
-- **Efficient resolution skipping.** The lockfile enables Bazel to skip the
- resolution process if there are no changes in the project dependencies since
- the last build. This significantly improves build efficiency, especially in
- scenarios where resolution can be time-consuming.
-
-- **Stability and risk reduction.** The lockfile helps maintain stability by
- preventing unexpected updates or breaking changes in external libraries. By
- locking the dependencies to specific versions, the risk of introducing bugs
- due to incompatible or untested updates is reduced.
-
-## Lockfile Contents
-
-The lockfile contains all the necessary information to determine whether the
-project state has changed. It also includes the result of building the project
-in the current state. The lockfile consists of two main parts:
-
-1. Inputs of the module resolution, such as `moduleFileHash`, `flags` and
- `localOverrideHashes`, as well as the output of the resolution, which is
- `moduleDepGraph`.
-2. For each module extension, the lockfile includes inputs that affect it,
- represented by `transitiveDigest`, and the output of running that extension
- referred to as `generatedRepoSpecs`
-
-Here is an example that demonstrates the structure of the lockfile, along with
-explanations for each section:
-
-```json
-{
- "lockFileVersion": 1,
- "moduleFileHash": "b0f47b98a67ee15f9.......8dff8721c66b721e370",
- "flags": {
- "cmdRegistries": [
- "https://bcr.bazel.build/"
- ],
- "cmdModuleOverrides": {},
- "allowedYankedVersions": [],
- "envVarAllowedYankedVersions": "",
- "ignoreDevDependency": false,
- "directDependenciesMode": "WARNING",
- "compatibilityMode": "ERROR"
- },
- "localOverrideHashes": {
- "bazel_tools": "b5ae1fa37632140aff8.......15c6fe84a1231d6af9"
- },
- "moduleDepGraph": {
- "Installing using the binary installer
- -The binary installers are on Bazel's -[GitHub releases page](https://github.com/bazelbuild/bazel/releases). - -The installer contains the Bazel binary. Some additional libraries -must also be installed for Bazel to work. - -### Step 1: Install Xcode command line tools - -If you don't intend to use `ios_*` rules, it is sufficient to install the Xcode -command line tools package by using `xcode-select`: - -```posix-terminal -xcode-select --install -``` - -Otherwise, for `ios_*` rule support, you must have Xcode 6.1 or later with iOS -SDK 8.1 installed on your system. - -Download Xcode from the -[App Store](https://apps.apple.com/us/app/xcode/id497799835) or the -[Apple Developer site](https://developer.apple.com/download/more/?=xcode). - -Once Xcode is installed, accept the license agreement for all users with the -following command: - -```posix-terminal -sudo xcodebuild -license accept -``` - -### Step 2: Download the Bazel installer - -Next, download the Bazel binary installer named -`bazel-Installing using Homebrew
- -### Step 1: Install Homebrew on macOS - -Install Homebrew (a one-time step): - -```posix-terminal -/bin/bash -c "$(curl -fsSL \ -https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" -``` - -### Step 2: Install Bazel via Homebrew - -Install the Bazel package via Homebrew as follows: - -```posix-terminal -brew install bazel -``` - -All set! You can confirm Bazel is installed successfully by running the -following command: - -```posix-terminal -bazel --version -``` - -Once installed, you can upgrade to a newer version of Bazel using the -following command: - -```posix-terminal -brew upgrade bazel -``` diff --git a/6.5.0/install/redhat.mdx b/6.5.0/install/redhat.mdx deleted file mode 100644 index 9461d92..0000000 --- a/6.5.0/install/redhat.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: 'Installing Bazel on Fedora and CentOS' ---- - - -This page describes how to install Bazel on Fedora and CentOS. - -The Bazel team does not provide official packages for Fedora and CentOS. -Vincent Batts ([@vbatts](https://github.com/vbatts)) generously maintains -unofficial packages on -[Fedora COPR](https://copr.fedorainfracloud.org/coprs/vbatts/bazel/). - -The commands below must be run either via `sudo` or while logged in as `root`. - -Add `--allowerasing` when installing an upgrade from a previous major -version of the Bazel package. - -[The Bazelisk installer](/install/bazelisk) is an alternative to package installation. - -## Installing on Fedora 25+ - -1. The [DNF](https://fedoraproject.org/wiki/DNF) package manager can - install Bazel from the [COPR](https://copr.fedorainfracloud.org/) repository. - Install the `copr` plugin for DNF if you have not already done so. - - ```posix-terminal - dnf install dnf-plugins-core - ``` - -2. Run the following commands to add the Bazel repository and install the - package: - - ```posix-terminal - dnf copr enable vbatts/bazel - - dnf install bazel4 - ``` - -## Installing on CentOS 7 - -1. Download the corresponding `.repo` file from - [Fedora COPR](https://copr.fedorainfracloud.org/coprs/vbatts/bazel/repo/epel-7/vbatts-bazel-epel-7.repo) - and copy it to `/etc/yum.repos.d/`. - -2. Run the following command: - - ```posix-terminal - yum install bazel4 - ``` diff --git a/6.5.0/install/suse.mdx b/6.5.0/install/suse.mdx deleted file mode 100644 index 0ac88e3..0000000 --- a/6.5.0/install/suse.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: 'Installing Bazel on openSUSE Tumbleweed & Leap' ---- - - -This page describes how to install Bazel on openSUSE Tumbleweed and Leap. - -`NOTE:` The Bazel team does not officially maintain openSUSE support. For issues -using Bazel on openSUSE please file a ticket at [bugzilla.opensuse.org](https://bugzilla.opensuse.org/). - -Packages are provided for openSUSE Tumbleweed and Leap. You can find all -available Bazel versions via openSUSE's [software search](https://software.opensuse.org/search?utf8=%E2%9C%93&baseproject=ALL&q=bazel). - -The commands below must be run either via `sudo` or while logged in as `root`. - -## Installing Bazel on openSUSE - -Run the following commands to install the package. If you need a specific -version, you can install it via the specific `bazelXXX` package, otherwise, -just `bazel` is enough: - -To install the latest version of Bazel, run: - -```posix-terminal -zypper install bazel -``` - -You can also install a specific version of Bazel by specifying the package -version with `bazel{{ '' }}version{{ '' }}`. For example, to install -Bazel 4.2, run: - -```posix-terminal -zypper install bazel4.2 -``` diff --git a/6.5.0/install/ubuntu.mdx b/6.5.0/install/ubuntu.mdx deleted file mode 100644 index 5703e30..0000000 --- a/6.5.0/install/ubuntu.mdx +++ /dev/null @@ -1,155 +0,0 @@ ---- -title: 'Installing Bazel on Ubuntu' ---- - - -This page describes the options for installing Bazel on Ubuntu. -It also provides links to the Bazel completion scripts and the binary installer, -if needed as a backup option (for example, if you don't have admin access). - -Supported Ubuntu Linux platforms: - -* 20.04 (LTS) -* 18.04 (LTS) - -Bazel should be compatible with other Ubuntu releases and Debian -"stretch" and above, but is untested and not guaranteed to work. - -Install Bazel on Ubuntu using one of the following methods: - -* *Recommended*: [Use Bazelisk](/install/bazelisk) -* [Use our custom APT repository](#install-on-ubuntu) -* [Use the binary installer](#binary-installer) -* [Compile Bazel from source](/install/compile-source) - -**Note:** For Arm-based systems, the APT repository does not contain an `arm64` -release, and there is no binary installer available. Either use Bazelisk or -compile from source. - -Bazel comes with two completion scripts. After installing Bazel, you can: - -* Access the [bash completion script](/install/completion#bash) -* Install the [zsh completion script](/install/completion#zsh) - -### Step 1: Add Bazel distribution URI as a package source - -## Using Bazel's apt repository - -**Note:** This is a one-time setup step. - -```posix-terminal -sudo apt install apt-transport-https curl gnupg -curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg -sudo mv bazel-archive-keyring.gpg /usr/share/keyrings -echo "deb [arch=amd64 signed-by=/usr/share/keyrings/bazel-archive-keyring.gpg] https://storage.googleapis.com/bazel-apt stable jdk1.8" | sudo tee /etc/apt/sources.list.d/bazel.list -``` - -The component name "jdk1.8" is kept only for legacy reasons and doesn't relate -to supported or included JDK versions. Bazel releases are Java-version agnostic. -Changing the "jdk1.8" component name would break existing users of the repo. - -### Step 2: Install and update Bazel - -```posix-terminal -sudo apt update && sudo apt install bazel -``` - -Once installed, you can upgrade to a newer version of Bazel as part of your normal system updates: - -```posix-terminal -sudo apt update && sudo apt full-upgrade -``` - -The `bazel` package always installs the latest stable version of Bazel. You -can install specific, older versions of Bazel in addition to the latest one, -such as this: - -```posix-terminal -sudo apt install bazel-1.0.0 -``` - -This installs Bazel 1.0.0 as `/usr/bin/bazel-1.0.0` on your system. This -can be useful if you need a specific version of Bazel to build a project, for -example because it uses a `.bazelversion` file to explicitly state with which -Bazel version it should be built. - -Optionally, you can set `bazel` to a specific version by creating a symlink: - -```posix-terminal -sudo ln -s /usr/bin/bazel-1.0.0 /usr/bin/bazel -bazel --version # 1.0.0 -``` - -### Step 3: Install a JDK (optional) - -Bazel includes a private, bundled JRE as its runtime and doesn't require you to -install any specific version of Java. - -However, if you want to build Java code using Bazel, you have to install a JDK. - -```posix-terminal -# Ubuntu 16.04 (LTS) uses OpenJDK 8 by default: -sudo apt install openjdk-8-jdk - -# Ubuntu 18.04 (LTS) uses OpenJDK 11 by default: -sudo apt install openjdk-11-jdk -``` - -## Using the binary installer - -Generally, you should use the apt repository, but the binary installer -can be useful if you don't have admin permissions on your machine or -can't add custom repositories. - -The binary installers can be downloaded from Bazel's [GitHub releases page](https://github.com/bazelbuild/bazel/releases). - -The installer contains the Bazel binary and extracts it into your `$HOME/bin` -folder. Some additional libraries must be installed manually for Bazel to work. - -### Step 1: Install required packages - -Bazel needs a C++ compiler and unzip / zip in order to work: - -```posix-terminal -sudo apt install g++ unzip zip -``` - -If you want to build Java code using Bazel, install a JDK: - -```posix-terminal -# Ubuntu 16.04 (LTS) uses OpenJDK 8 by default: -sudo apt-get install openjdk-8-jdk - -# Ubuntu 18.04 (LTS) uses OpenJDK 11 by default: -sudo apt-get install openjdk-11-jdk -``` - -### Step 2: Run the installer - -Next, download the Bazel binary installer named `bazel-{{ '' }}version{{ '' }}-installer-linux-x86_64.sh` -from the [Bazel releases page on GitHub](https://github.com/bazelbuild/bazel/releases). - -Run it as follows: - -```posix-terminal -chmod +x bazel-{{ '' }}version{{ '' }}-installer-linux-x86_64.sh - -./bazel-{{ '' }}version{{ '' }}-installer-linux-x86_64.sh --user -``` - -The `--user` flag installs Bazel to the `$HOME/bin` directory on your system and -sets the `.bazelrc` path to `$HOME/.bazelrc`. Use the `--help` command to see -additional installation options. - -### Step 3: Set up your environment - -If you ran the Bazel installer with the `--user` flag as above, the Bazel -executable is installed in your `$HOME/bin` directory. -It's a good idea to add this directory to your default paths, as follows: - -```posix-terminal -export PATH="$PATH:$HOME/bin" -``` - -You can also add this command to your `~/.bashrc` or `~/.zshrc` file to make it -permanent. diff --git a/6.5.0/migrate/index.mdx b/6.5.0/migrate/index.mdx deleted file mode 100644 index 215de29..0000000 --- a/6.5.0/migrate/index.mdx +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: 'Migrating to Bazel' ---- - - -This page links to migration guides for Bazel. - -* [Maven](/migrate/maven) -* [Xcode](/migrate/xcode) -* [CocoaPods](/migrate/cocoapods) diff --git a/6.5.0/migrate/maven.mdx b/6.5.0/migrate/maven.mdx deleted file mode 100644 index 17ecd33..0000000 --- a/6.5.0/migrate/maven.mdx +++ /dev/null @@ -1,256 +0,0 @@ ---- -title: 'Migrating from Maven to Bazel' ---- - - -This page describes how to migrate from Maven to Bazel, including the -prerequisites and installation steps. It describes the differences -between Maven and Bazel, and provides a migration example using the -Guava project. - -When migrating from any build tool to Bazel, it's best to have both build -tools running in parallel until you have fully migrated your development team, -CI system, and any other relevant systems. You can run Maven and Bazel in the -same repository. - -Note: While Bazel supports downloading and publishing Maven artifacts with -[rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external), -it does not directly support Maven-based plugins. Maven plugins can't be -directly run by Bazel since there's no Maven compatibility layer. - -## Before you begin - -* [Install Bazel](/install) if it's not yet installed. -* If you're new to Bazel, go through the tutorial - [Introduction to Bazel: Build Java](/tutorials/java) before you start - migrating. The tutorial explains Bazel's concepts, structure, and label - syntax. - -## Differences between Maven and Bazel - -* Maven uses top-level `pom.xml` file(s). Bazel supports multiple build - files and multiple targets per `BUILD` file, allowing for builds that - are more incremental than Maven's. -* Maven takes charge of steps for the deployment process. Bazel does - not automate deployment. -* Bazel enables you to express dependencies between languages. -* As you add new sections to the project, with Bazel you may need to add new - `BUILD` files. Best practice is to add a `BUILD` file to each new Java package. - -## Migrate from Maven to Bazel - -The steps below describe how to migrate your project to Bazel: - -1. [Create the WORKSPACE file](#1-build) -2. [Create one BUILD file](#2-build) -3. [Create more BUILD files](#3-build) -4. [Build using Bazel](#4-build) - -Examples below come from a migration of the -[Guava project](https://github.com/google/guava) from Maven to Bazel. -The Guava project used is release `v31.1`. The examples using Guava do not walk through -each step in the migration, but they do show the files and contents that are -generated or added manually for the migration. - -``` -$ git clone https://github.com/google/guava.git && cd guava -$ git checkout v31.1 -``` - -### 1. Create the WORKSPACE file - -Create a file named `WORKSPACE` at the root of your project. If your project -has no external dependencies, the workspace file can be empty. - -If your project depends on files or packages that are not in one of the -project's directories, specify these external dependencies in the workspace -file. To automate the listing of external dependencies for the workspace file, -use `rules_jvm_external`. For instructions about using this ruleset, see -[the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external). - -Note: The previously recommended tool, `generate_workspace`, is no longer -maintained by the Bazel team. - -#### Guava project example: external dependencies - -You can list the external dependencies of the -[Guava project](https://github.com/google/guava) with the -[`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external) -ruleset. - -Add the following snippet to the `WORKSPACE` file: - -```python -load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") - -RULES_JVM_EXTERNAL_TAG = "4.3" -RULES_JVM_EXTERNAL_SHA = "6274687f6fc5783b589f56a2f1ed60de3ce1f99bc4e8f9edef3de43bdf7c6e74" - -http_archive( - name = "rules_jvm_external", - sha256 = RULES_JVM_EXTERNAL_SHA, - strip_prefix = "rules_jvm_external-%s" % RULES_JVM_EXTERNAL_TAG, - url = "https://github.com/bazelbuild/rules_jvm_external/archive/%s.zip" % RULES_JVM_EXTERNAL_TAG, -) - -load("@rules_jvm_external//:defs.bzl", "maven_install") - -maven_install( - artifacts = [ - "com.google.code.findbugs:jsr305:3.0.2", - "com.google.errorprone:error_prone_annotations:2.11.0", - "com.google.j2objc:j2objc-annotations:1.3", - "org.codehaus.mojo:animal-sniffer-annotations:1.20", - "org.checkerframework:checker-qual:3.12.0", - ], - repositories = [ - "https://repo1.maven.org/maven2", - ], -) -``` - -### 2. Create one BUILD file - -Now that you have your workspace defined and external dependencies (if -applicable) listed, you need to create `BUILD` files to describe how your project -should be built. Unlike Maven with its one `pom.xml` file, Bazel can use many -`BUILD` files to build a project. These files specify multiple build targets, -which allow Bazel to produce incremental builds. - -Add `BUILD` files in stages. Start with adding one `BUILD` file -at the root of your project and using it to do an initial build using Bazel. -Then, you refine your build by adding more `BUILD` files with more granular -targets. - -1. In the same directory as your `WORKSPACE` file, create a text file and - name it `BUILD`. - -2. In this `BUILD` file, use the appropriate rule to create one target to - build your project. Here are some tips: - - * Use the appropriate rule: - * To build projects with a single Maven module, use the - `java_library` rule as follows: - - ```python - java_library( - name = "everything", - srcs = glob(["src/main/java/**/*.java"]), - resources = glob(["src/main/resources/**"]), - deps = ["//:all-external-targets"], - ) - ``` - * To build projects with multiple Maven modules, use the - `java_library` rule as follows: - - ```python - java_library( - name = "everything", - srcs = glob([ - "Module1/src/main/java/**/*.java", - "Module2/src/main/java/**/*.java", - ... - ]), - resources = glob([ - "Module1/src/main/resources/**", - "Module2/src/main/resources/**", - ... - ]), - deps = ["//:all-external-targets"], - ) - ``` - * To build binaries, use the `java_binary` rule: - - ```python - java_binary( - name = "everything", - srcs = glob(["src/main/java/**/*.java"]), - resources = glob(["src/main/resources/**"]), - deps = ["//:all-external-targets"], - main_class = "com.example.Main" - ) - ``` - * Specify the attributes: - * `name`: Give the target a meaningful name. In the examples above, - the target is called "everything." - * `srcs`: Use globbing to list all .java files in your project. - * `resources`: Use globbing to list all resources in your project. - * `deps`: You need to determine which external dependencies your - project needs. For example, if you generated a list of external - dependencies using the tool `generate_workspace`, the dependencies - for `java_library` are the libraries listed in the - `generated_java_libraries` macro. - * Take a look at the - [example below of this top-level BUILD file](#guava-2) from - the migration of the Guava project. - -3. Now that you have a `BUILD` file at the root of your project, build - your project to ensure that it works. On the command line, from your - workspace directory, use `bazel build //:everything` to build your - project with Bazel. - - The project has now been successfully built with Bazel. You will need - to add more `BUILD` files to allow incremental builds of the project. - -#### Guava project example: start with one BUILD file - -When migrating the Guava project to Bazel, initially one `BUILD` file is used -to build the entire project. Here are the contents of this initial `BUILD` -file in the workspace directory: - -```python -java_library( - name = "everything", - srcs = glob([ - "guava/src/**/*.java", - "futures/failureaccess/src/**/*.java", - ]), - deps = [ - "@maven//:com_google_code_findbugs_jsr305", - "@maven//:com_google_errorprone_error_prone_annotations", - "@maven//:com_google_j2objc_j2objc_annotations", - "@maven//:org_checkerframework_checker_qual", - "@maven//:org_codehaus_mojo_animal_sniffer_annotations", - ], -) -``` - -### 3. Create more BUILD files (optional) - -Bazel does work with just one `BUILD file`, as you saw after completing your first -build. You should still consider breaking the build into smaller chunks by -adding more `BUILD` files with granular targets. - -Multiple `BUILD` files with multiple targets will give the build increased -granularity, allowing: - -* increased incremental builds of the project, -* increased parallel execution of the build, -* better maintainability of the build for future users, and -* control over visibility of targets between packages, which can prevent - issues such as libraries containing implementation details leaking into - public APIs. - -Tips for adding more `BUILD` files: - -* You can start by adding a `BUILD` file to each Java package. Start with - Java packages that have the fewest dependencies and work you way up - to packages with the most dependencies. -* As you add `BUILD` files and specify targets, add these new targets to the - `deps` sections of targets that depend on them. Note that the `glob()` - function does not cross package boundaries, so as the number - of packages grows the files matched by `glob()` will shrink. -* Any time you add a `BUILD` file to a `main` directory, ensure that you add - a `BUILD` file to the corresponding `test` directory. -* Take care to limit visibility properly between packages. -* To simplify troubleshooting errors in your setup of `BUILD` files, ensure - that the project continues to build with Bazel as you add each build - file. Run `bazel build //...` to ensure all of your targets still build. - -### 4. Build using Bazel - -You've been building using Bazel as you add `BUILD` files to validate the setup -of the build. - -When you have `BUILD` files at the desired granularity, you can use Bazel -to produce all of your builds. diff --git a/6.5.0/migrate/xcode.mdx b/6.5.0/migrate/xcode.mdx deleted file mode 100644 index d867963..0000000 --- a/6.5.0/migrate/xcode.mdx +++ /dev/null @@ -1,271 +0,0 @@ ---- -title: 'Migrating from Xcode to Bazel' ---- - - -This page describes how to build or test an Xcode project with Bazel. It -describes the differences between Xcode and Bazel, and provides the steps -for converting an Xcode project to a Bazel project. It also provides -troubleshooting solutions to address common errors. - -## Differences between Xcode and Bazel - -* Bazel requires you to explicitly specify every build target and its - dependencies, plus the corresponding build settings via build rules. - -* Bazel requires all files on which the project depends to be present - within the workspace directory or specified as imports in the `WORKSPACE` - file. - -* When building Xcode projects with Bazel, the `BUILD` file(s) become the - source of truth. If you work on the project in Xcode, you must generate a - new version of the Xcode project that matches the `BUILD` files using - [rules_xcodeproj](https://github.com/buildbuddy-io/rules_xcodeproj/) - whenever you update the `BUILD` files. Certain changes to the `BUILD` files - such as adding dependencies to a target don't require regenerating the - project which can speed up development. If you're not using Xcode, the - `bazel build` and `bazel test` commands provide build and test capabilities - with certain limitations described later in this guide. - -## Before you begin - -Before you begin, do the following: - -1. [Install Bazel](/install) if you have not already done so. - -2. If you're not familiar with Bazel and its concepts, complete the - [iOS app tutorial](/tutorials/ios-app). You should understand the Bazel - workspace, including the `WORKSPACE` and `BUILD` files, as well as the - concepts of targets, build rules, and Bazel packages. - -3. Analyze and understand the project's dependencies. - -### Analyze project dependencies - -Unlike Xcode, Bazel requires you to explicitly declare all dependencies for -every target in the `BUILD` file. - -For more information on external dependencies, see -[Working with external dependencies](/docs/external). - -## Build or test an Xcode project with Bazel - -To build or test an Xcode project with Bazel, do the following: - -1. [Create the `WORKSPACE` file](#create-workspace) - -2. [(Experimental) Integrate SwiftPM dependencies](#integrate-swiftpm) - -3. [Create a `BUILD` file:](#create-build-file) - - a. [Add the application target](#add-app-target) - - b. [(Optional) Add the test target(s)](#add-test-target) - - c. [Add the library target(s)](#add-library-target) - -4. [(Optional) Granularize the build](#granularize-build) - -5. [Run the build](#run-build) - -6. [Generate the Xcode project with rules_xcodeproj](#generate-the-xcode-project-with-rules_xcodeproj) - -### Step 1: Create the `WORKSPACE` file - -Create a `WORKSPACE` file in a new directory. This directory becomes the Bazel -workspace root. If the project uses no external dependencies, this file can be -empty. If the project depends on files or packages that are not in one of the -project's directories, specify these external dependencies in the `WORKSPACE` -file. - -Note: Place the project source code within the directory tree containing the - `WORKSPACE` file. - -### Step 2: (Experimental) Integrate SwiftPM dependencies - -To integrate SwiftPM dependencies into the Bazel workspace with [swift_bazel](https://github.com/cgrindel/swift_bazel), -you must convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/). - -Note: SwiftPM support is a manual process with many variables. -SwiftPM integration with Bazel has not been fully verified and is not -officially supported. - -### Step 3: Create a `BUILD` file - -Once you have defined the workspace and external dependencies, you need to -create a `BUILD` file that tells Bazel how the project is structured. Create -the `BUILD` file at the root of the Bazel workspace and configure it to do an -initial build of the project as follows: - -* [Step 3a: Add the application target](#step-3a-add-the-application-target) -* [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s) -* [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s) - -**Tip:** To learn more about packages and other Bazel concepts, see -[Workspaces, packages, and targets](/concepts/build-ref). - -#### Step 3a: Add the application target - -Add a [`macos_application`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_application) -or an [`ios_application`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-ios.md#ios_application) -rule target. This target builds a macOS or iOS application bundle, respectively. -In the target, specify the following at the minimum: - -* `bundle_id` - the bundle ID (reverse-DNS path followed by app name) of the - binary. - -* `provisioning_profile` - provisioning profile from your Apple Developer - account (if building for an iOS device device). - -* `families` (iOS only) - whether to build the application for iPhone, iPad, - or both. - -* `infoplists` - list of .plist files to merge into the final Info.plist file. - -* `minimum_os_version` - the minimum version of macOS or iOS that the - application supports. This ensures Bazel builds the application with the - correct API levels. - -#### Step 3b: (Optional) Add the test target(s) - -Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support -running library-based unit tests on iOS and macOS, as well as application-based -tests on macOS. For application-based tests on iOS or UI tests on either -platform, Bazel will build the test outputs but the tests must run within Xcode -through a project generated with rules_xcodeproj. Add test targets as follows: - -* [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test) to run library-based and application-based unit tests on a macOS. - -* [`ios_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-ios.md#ios_unit_test) - to run library-based unit tests on iOS. For tests requiring the iOS - simulator, Bazel will build the test outputs but not run the tests. You must - [generate an Xcode project with rules_xcodeproj](#generate-the-xcode-project-with-rules_xcodeproj) - and run the tests from within Xcode. - -* [`ios_ui_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-ios.md#ios_ui_test) - to build outputs required to run user interface tests in the iOS simulator - using Xcode. You must [generate an Xcode project with rules_xcodeproj](#generate-the-xcode-project-with-rules_xcodeproj) - and run the tests from within Xcode. Bazel cannot natively run UI tests. - -At the minimum, specify a value for the `minimum_os_version` attribute. While -other packaging attributes, such as `bundle_identifier` and `infoplists`, -default to most commonly used values, ensure that those defaults are compatible -with the project and adjust them as necessary. For tests that require the iOS -simulator, also specify the `ios_application` target name as the value of the -`test_host` attribute. - - -#### Step 3c: Add the library target(s) - -Add an [`objc_library`](/reference/be/objective-c#objc_library) -target for each Objective-C library and a [`swift_library`](https://github.com/bazelbuild/rules_swift/blob/master/doc/rules.md#swift_library) -target for each Swift library on which the application and/or tests depend. - - -Add the library targets as follows: - -* Add the application library targets as dependencies to the application - targets. - -* Add the test library targets as dependencies to the test targets. - -* List the implementation sources in the `srcs` attribute. - -* List the headers in the `hdrs` attribute. - -Note: You can use the [`glob`](/reference/be/functions#glob) -function to include all sources and/or headers of a certain type. Use it -carefully as it might include files you do not want Bazel to build. - -You can browse existing examples for various types of applications directly in the -[rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For example: - -* [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos) - -* [iOS applications targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/ios) - -* [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform) - - -For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple). - -At this point, it is a good idea to test the build: - -`bazel build //:| Query | -Target Built | -Output | -
|---|---|---|
| bazel cquery "//x:tool" | -//x:tool | -//x:tool(targetconfig) | -
| bazel cquery "//x:tool" --universe_scope="//x:my_gen" | -//x:my_gen | -//x:tool(hostconfig) | -
--bazelrc=file
-
- This flag is optional but can also be specified multiple times.
-
- `/dev/null` indicates that all further `--bazelrc`s will be ignored, which
- is useful to disable the search for a user rc file, such as in release builds.
-
- For example:
-
- ```
- --bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc
- ```
-
- - `x.rc` and `y.rc` are read.
- - `z.rc` is ignored due to the prior `/dev/null`.
-
-In addition to this optional configuration file, Bazel looks for a global rc
-file. For more details, see the [global bazelrc section](#global-bazelrc).
-
-
-### `.bazelrc` syntax and semantics
-
-Like all UNIX "rc" files, the `.bazelrc` file is a text file with a line-based
-grammar. Empty lines and lines starting with `#` (comments) are ignored. Each
-line contains a sequence of words, which are tokenized according to the same
-rules as the Bourne shell.
-
-#### Imports
-
-Lines that start with `import` or `try-import` are special: use these to load
-other "rc" files. To specify a path that is relative to the workspace root,
-write `import %workspace%/path/to/bazelrc`.
-
-The difference between `import` and `try-import` is that Bazel fails if the
-`import`'ed file is missing (or can't be read), but not so for a `try-import`'ed
-file.
-
-Import precedence:
-
-- Options in the imported file take precedence over options specified before
- the import statement.
-- Options specified after the import statement take precedence over the
- options in the imported file.
-- Options in files imported later take precedence over files imported earlier.
-
-#### Option defaults
-
-Most lines of a bazelrc define default option values. The first word on each
-line specifies when these defaults are applied:
-
-- `startup`: startup options, which go before the command, and are described
- in `bazel help startup_options`.
-- `common`: options that should be applied to all Bazel commands that support
- them. If a command does not support an option specified in this way, the
- option is ignored so long as it is valid for *some* other Bazel command.
- Note that this only applies to option names: If the current command accepts
- an option with the specified name, but doesn't support the specified value,
- it will fail.
-- `always`: options that apply to all Bazel commands. If a command does not
- support an option specified in this way, it will fail.
-- _`command`_: Bazel command, such as `build` or `query` to which the options
- apply. These options also apply to all commands that inherit from the
- specified command. (For example, `test` inherits from `build`.)
-
-Each of these lines may be used more than once and the arguments that follow the
-first word are combined as if they had appeared on a single line. (Users of CVS,
-another tool with a "Swiss army knife" command-line interface, will find the
-syntax similar to that of `.cvsrc`.) For example, the lines:
-
-```posix-terminal
-build --test_tmpdir=/tmp/foo --verbose_failures
-
-build --test_tmpdir=/tmp/bar
-```
-
-are combined as:
-
-```posix-terminal
-build --test_tmpdir=/tmp/foo --verbose_failures --test_tmpdir=/tmp/bar
-```
-
-so the effective flags are `--verbose_failures` and `--test_tmpdir=/tmp/bar`.
-
-Option precedence:
-
-- Options on the command line always take precedence over those in rc files.
- For example, if a rc file says `build -c opt` but the command line flag is
- `-c dbg`, the command line flag takes precedence.
-- Within the rc file, precedence is governed by specificity: lines for a more
- specific command take precedence over lines for a less specific command.
-
- Specificity is defined by inheritance. Some commands inherit options from
- other commands, making the inheriting command more specific than the base
- command. For example `test` inherits from the `build` command, so all `bazel
- build` flags are valid for `bazel test`, and all `build` lines apply also to
- `bazel test` unless there's a `test` line for the same option. If the rc
- file says:
-
- ```posix-terminal
- test -c dbg --test_env=PATH
-
- build -c opt --verbose_failures
- ```
-
- then `bazel build //foo` will use `-c opt --verbose_failures`, and `bazel
- test //foo` will use `--verbose_failures -c dbg --test_env=PATH`.
-
- The inheritance (specificity) graph is:
-
- * Every command inherits from `common`
- * The following commands inherit from (and are more specific than)
- `build`: `test`, `run`, `clean`, `mobile-install`, `info`,
- `print_action`, `config`, `cquery`, and `aquery`
- * `coverage` inherits from `test`
-
-- Two lines specifying options for the same command at equal specificity are
- parsed in the order in which they appear within the file.
-
-- Because this precedence rule does not match the file order, it helps
- readability if you follow the precedence order within rc files: start with
- `common` options at the top, and end with the most-specific commands at the
- bottom of the file. This way, the order in which the options are read is the
- same as the order in which they are applied, which is more intuitive.
-
-The arguments specified on a line of an rc file may include arguments that are
-not options, such as the names of build targets, and so on. These, like the
-options specified in the same files, have lower precedence than their siblings
-on the command line, and are always prepended to the explicit list of non-
-option arguments.
-
-#### `--config`
-
-In addition to setting option defaults, the rc file can be used to group options
-and provide a shorthand for common groupings. This is done by adding a `:name`
-suffix to the command. These options are ignored by default, but will be
-included when the option --config=name is present,
-either on the command line or in a `.bazelrc` file, recursively, even inside of
-another config definition. The options specified by `command:name` will only be
-expanded for applicable commands, in the precedence order described above.
-
-Note: Configs can be defined in any `.bazelrc` file, and that all lines of
-the form `command:name` (for applicable commands) will be expanded, across the
-different rc files. In order to avoid name conflicts, we suggest that configs
-defined in personal rc files start with an underscore (`_`) to avoid
-unintentional name sharing.
-
-`--config=foo` expands to the options defined in
-[the rc files](#bazelrc-file-locations) "in-place" so that the options
-specified for the config have the same precedence that the `--config=foo` option
-had.
-
-This syntax does not extend to the use of `startup` to set
-[startup options](#option-defaults). Setting
-`startup:config-name --some_startup_option` in the .bazelrc will be ignored.
-
-#### Example
-
-Here's an example `~/.bazelrc` file:
-
-```
-# Bob's Bazel option defaults
-
-startup --host_jvm_args=-XX:-UseParallelGC
-import /home/bobs_project/bazelrc
-build --show_timestamps --keep_going --jobs 600
-build --color=yes
-query --keep_going
-
-# Definition of --config=memcheck
-build:memcheck --strip=never --test_timeout=3600
-```
-
-### Other files governing Bazel's behavior
-
-#### `.bazelignore`
-
-You can specify directories within the workspace
-that you want Bazel to ignore, such as related projects
-that use other build systems. Place a file called
-`.bazelignore` at the root of the workspace
-and add the directories you want Bazel to ignore, one per
-line. Entries are relative to the workspace root.
-
-### The global bazelrc file
-
-Bazel reads optional bazelrc files in this order:
-- System rc-file located at `etc/bazel.bazelrc`.
-- Workspace rc-file located at `$workspace/tools/bazel.rc`.
-- Home rc-file localted at `$HOME/.bazelrc`
-
-Each bazelrc file listed here has a corresponding flag which can be used to disable them (e.g. `--nosystem_rc`, `--noworkspace_rc`, `--nohome_rc`). You can also make Bazel ignore all bazelrcs by passing the `--ignore_all_rc_files` startup option.
diff --git a/6.5.0/run/client-server.mdx b/6.5.0/run/client-server.mdx
deleted file mode 100644
index be1f600..0000000
--- a/6.5.0/run/client-server.mdx
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: 'Client/server implementation'
----
-
-
-
-The Bazel system is implemented as a long-lived server process. This allows it
-to perform many optimizations not possible with a batch-oriented implementation,
-such as caching of BUILD files, dependency graphs, and other metadata from one
-build to the next. This improves the speed of incremental builds, and allows
-different commands, such as `build` and `query` to share the same cache of
-loaded packages, making queries very fast.
-
-When you run `bazel`, you're running the client. The client finds the server
-based on the output base, which by default is determined by the path of the base
-workspace directory and your userid, so if you build in multiple workspaces,
-you'll have multiple output bases and thus multiple Bazel server processes.
-Multiple users on the same workstation can build concurrently in the same
-workspace because their output bases will differ (different userids). If the
-client cannot find a running server instance, it starts a new one. The server
-process will stop after a period of inactivity (3 hours, by default, which can
-be modified using the startup option `--max_idle_secs`).
-
-For the most part, the fact that there is a server running is invisible to the
-user, but sometimes it helps to bear this in mind. For example, if you're
-running scripts that perform a lot of automated builds in different directories,
-it's important to ensure that you don't accumulate a lot of idle servers; you
-can do this by explicitly shutting them down when you're finished with them, or
-by specifying a short timeout period.
-
-The name of a Bazel server process appears in the output of `ps x` or `ps -e f`
-as bazel(dirname), where _dirname_ is the basename of the
-directory enclosing the root of your workspace directory. For example:
-
-```posix-terminal
-ps -e f
-16143 ? Sl 3:00 bazel(src-johndoe2) -server -Djava.library.path=...
-```
-
-This makes it easier to find out which server process belongs to a given
-workspace. (Beware that with certain other options to `ps`, Bazel server
-processes may be named just `java`.) Bazel servers can be stopped using the
-[shutdown](/docs/user-manual#shutdown) command.
-
-When running `bazel`, the client first checks that the server is the appropriate
-version; if not, the server is stopped and a new one started. This ensures that
-the use of a long-running server process doesn't interfere with proper
-versioning.
diff --git a/6.5.0/run/scripts.mdx b/6.5.0/run/scripts.mdx
deleted file mode 100644
index 612bace..0000000
--- a/6.5.0/run/scripts.mdx
+++ /dev/null
@@ -1,125 +0,0 @@
----
-title: 'Calling Bazel from scripts'
----
-
-
-You can call Bazel from scripts to perform a build, run tests, or query
-the dependency graph. Bazel has been designed to enable effective scripting, but
-this section lists some details to bear in mind to make your scripts more
-robust.
-
-### Choosing the output base
-
-The `--output_base` option controls where the Bazel process should write the
-outputs of a build to, as well as various working files used internally by
-Bazel, one of which is a lock that guards against concurrent mutation of the
-output base by multiple Bazel processes.
-
-Choosing the correct output base directory for your script depends on several
-factors. If you need to put the build outputs in a specific location, this will
-dictate the output base you need to use. If you are making a "read only" call to
-Bazel (such as `bazel query`), the locking factors will be more important. In
-particular, if you need to run multiple instances of your script concurrently,
-you will need to give each one a different (or random) output base.
-
-If you use the default output base value, you will be contending for the same
-lock used by the user's interactive Bazel commands. If the user issues
-long-running commands such as builds, your script will have to wait for those
-commands to complete before it can continue.
-
-### Notes about server mode
-
-By default, Bazel uses a long-running [server process](/docs/client-server) as an
-optimization. When running Bazel in a script, don't forget to call `shutdown`
-when you're finished with the server, or, specify `--max_idle_secs=5` so that
-idle servers shut themselves down promptly.
-
-### What exit code will I get?
-
-Bazel attempts to differentiate failures due to the source code under
-consideration from external errors that prevent Bazel from executing properly.
-Bazel execution can result in following exit codes:
-
-**Exit Codes common to all commands:**
-
-- `0` - Success
-- `2` - Command Line Problem, Bad or Illegal flags or command combination, or
- Bad Environment Variables. Your command line must be modified.
-- `8` - Build Interrupted but we terminated with an orderly shutdown.
-- `9` - The server lock is held and `--noblock_for_lock` was passed.
-- `32` - External Environment Failure not on this machine.
-
-- `33` - Bazel ran out of memory and crashed. You need to modify your command line.
-- `34` - Reserved for Google-internal use.
-- `35` - Reserved for Google-internal use.
-- `36` - Local Environmental Issue, suspected permanent.
-- `37` - Unhandled Exception / Internal Bazel Error.
-- `38` - Reserved for Google-internal use.
-- `39` - Blobs required by Bazel are evicted from Remote Cache.
-- `41-44` - Reserved for Google-internal use.
-- `45` - Error publishing results to the Build Event Service.
-- `47` - Reserved for Google-internal use.
-
-**Return codes for commands `bazel build`, `bazel test`:**
-
-- `1` - Build failed.
-- `3` - Build OK, but some tests failed or timed out.
-- `4` - Build successful but no tests were found even though testing was
- requested.
-
-
-**For `bazel run`:**
-
-- `1` - Build failed.
-- If the build succeeds but the executed subprocess returns a non-zero exit
- code it will be the exit code of the command as well.
-
-**For `bazel query`:**
-
-- `3` - Partial success, but the query encountered 1 or more errors in the
- input BUILD file set and therefore the results of the operation are not 100%
- reliable. This is likely due to a `--keep_going` option on the command line.
-- `7` - Command failure.
-
-Future Bazel versions may add additional exit codes, replacing generic failure
-exit code `1` with a different non-zero value with a particular meaning.
-However, all non-zero exit values will always constitute an error.
-
-
-### Reading the .bazelrc file
-
-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
-.bazelrc file by using the option `--bazelrc=/dev/null`. If you want to perform
-a build using the user's preferred settings, the default behavior is better.
-
-### Command log
-
-The Bazel output is also available in a command log file which you can find with
-the following command:
-
-```posix-terminal
-bazel info command_log
-```
-
-The command log file contains the interleaved stdout and stderr streams of the
-most recent Bazel command. Note that running `bazel info` will overwrite the
-contents of this file, since it then becomes the most recent Bazel command.
-However, the location of the command log file will not change unless you change
-the setting of the `--output_base` or `--output_user_root` options.
-
-### Parsing output
-
-The Bazel output is quite easy to parse for many purposes. Two options that may
-be helpful for your script are `--noshow_progress` which suppresses progress
-messages, and --show_result n, which controls whether or
-not "build up-to-date" messages are printed; these messages may be parsed to
-discover which targets were successfully built, and the location of the output
-files they created. Be sure to specify a very large value of _n_ if you rely on
-these messages.
-
-## Troubleshooting performance by profiling
-
-See the [Performance Profiling](/rules/performance#performance-profiling) section.
diff --git a/6.5.0/start/android-app.mdx b/6.5.0/start/android-app.mdx
deleted file mode 100644
index 67ce43e..0000000
--- a/6.5.0/start/android-app.mdx
+++ /dev/null
@@ -1,422 +0,0 @@
----
-title: 'Bazel Tutorial: Build an Android App'
----
-
-
-This tutorial covers how to build a simple Android app using Bazel.
-
-Bazel supports building Android apps using the
-[Android rules](/reference/be/android).
-
-This tutorial is intended for Windows, macOS and Linux users and does not
-require experience with Bazel or Android app development. You do not need to
-write any Android code in this tutorial.
-
-## What you'll learn
-
-In this tutorial you learn how to:
-
-* Set up your environment by installing Bazel and Android Studio, and
- downloading the sample project.
-* Set up a Bazel [workspace](/reference/be/workspace) that contains the source code
- for the app and a `WORKSPACE` file that identifies the top level of the
- workspace directory.
-* Update the `WORKSPACE` file to contain references to the required
- external dependencies, like the Android SDK.
-* Create a `BUILD` file.
-* Build the app with Bazel.
-* Deploy and run the app on an Android emulator or physical device.
-
-## Before you begin
-
-### Install Bazel
-
-Before you begin the tutorial, install the following software:
-
-* **Bazel.** To install, follow the [installation instructions](/install).
-* **Android Studio.** To install, follow the steps to [download Android
- Studio](https://developer.android.com/sdk/index.html).
- Execute the setup wizard to download the SDK and configure your environment.
-* (Optional) **Git.** Use `git` to download the Android app project.
-
-### Get the sample project
-
-For the sample project, use a basic Android app project in
-[Bazel's examples repository](https://github.com/bazelbuild/examples).
-
-This app has a single button that prints a greeting when clicked:
-
-
-
-**Figure 1.** Android app button greeting.
-
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
-
-```posix-terminal
-git clone https://github.com/bazelbuild/examples
-```
-
-The sample project for this tutorial is in `examples/android/tutorial`. For
-the rest of the tutorial, you will be executing commands in this directory.
-
-### Review the source files
-
-Take a look at the source files for the app.
-
-```
-.
-├── README.md
-└── src
- └── main
- ├── AndroidManifest.xml
- └── java
- └── com
- └── example
- └── bazel
- ├── AndroidManifest.xml
- ├── Greeter.java
- ├── MainActivity.java
- └── res
- ├── layout
- │ └── activity_main.xml
- └── values
- ├── colors.xml
- └── strings.xml
-```
-
-The key files and directories are:
-
-| Name | Location |
-| ----------------------- | ---------------------------------------------------------------------------------------- |
-| Android manifest files | `src/main/AndroidManifest.xml` and `src/main/java/com/example/bazel/AndroidManifest.xml` |
-| Android source files | `src/main/java/com/example/bazel/MainActivity.java` and `Greeter.java` |
-| Resource file directory | `src/main/java/com/example/bazel/res/` |
-
-
-## Build with Bazel
-
-### Set up the workspace
-
-A [workspace](/concepts/build-ref#workspace) is a directory that contains the
-source files for one or more software projects, and has a `WORKSPACE` file at
-its root.
-
-The `WORKSPACE` file may be empty or may contain references to [external
-dependencies](/docs/external) required to build your project.
-
-First, run the following command to create an empty `WORKSPACE` file:
-
-| OS | Command |
-| ------------------------ | ----------------------------------- |
-| Linux, macOS | `touch WORKSPACE` |
-| Windows (Command Prompt) | `type nul > WORKSPACE` |
-| Windows (PowerShell) | `New-Item WORKSPACE -ItemType file` |
-
-### Running Bazel
-
-You can now check if Bazel is running correctly with the command:
-
-```posix-terminal
-bazel info workspace
-```
-
-If Bazel prints the path of the current directory, you're good to go! If the
-`WORKSPACE` file does not exist, you may see an error message like:
-
-```
-ERROR: The 'info' command is only supported from within a workspace.
-```
-
-### Integrate with the Android SDK
-
-Bazel needs to run the Android SDK
-[build tools](https://developer.android.com/tools/revisions/build-tools.html)
-to build the app. This means that you need to add some information to your
-`WORKSPACE` file so that Bazel knows where to find them.
-
-Add the following line to your `WORKSPACE` file:
-
-```python
-android_sdk_repository(name = "androidsdk")
-```
-
-This will use the Android SDK at the path referenced by the `ANDROID_HOME`
-environment variable, and automatically detect the highest API level and the
-latest version of build tools installed within that location.
-
-You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
-Assuming the SDK is installed to default locations, you can use the following
-commands to set the `ANDROID_HOME` variable:
-
-| OS | Command |
-| ------------------------ | --------------------------------------------------- |
-| Linux | `export ANDROID_HOME=$HOME/Android/Sdk/` |
-| macOS | `export ANDROID_HOME=$HOME/Library/Android/sdk` |
-| Windows (Command Prompt) | `set ANDROID_HOME=%LOCALAPPDATA%\Android\Sdk` |
-| Windows (PowerShell) | `$env:ANDROID_HOME="$env:LOCALAPPDATA\Android\Sdk"` |
-
-The above commands set the variable only for the current shell session. To make
-them permanent, run the following commands:
-
-| OS | Command |
-| ------------------------ | --------------------------------------------------- |
-| Linux | `echo "export ANDROID_HOME=$HOME/Android/Sdk/" >> ~/.bashrc` |
-| macOS | `echo "export ANDROID_HOME=$HOME/Library/Android/Sdk/" >> ~/.bashrc` |
-| Windows (Command Prompt) | `setx ANDROID_HOME "%LOCALAPPDATA%\Android\Sdk"` |
-| Windows (PowerShell) | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
-
-You can also explicitly specify the absolute path of the Android SDK,
-the API level, and the version of build tools to use by including the `path`,
-`api_level`, and `build_tools_version` attributes. If `api_level` and
-`build_tools_version` are not specified, the `android_sdk_repository` rule will
-use the respective latest version available in the SDK. You can specify any
-combination of these attributes, as long as they are present in the SDK, for
-example:
-
-```python
-android_sdk_repository(
- name = "androidsdk",
- path = "/path/to/Android/sdk",
- api_level = 25,
- build_tools_version = "30.0.3"
-)
-```
-
-On Windows, note that the `path` attribute must use the mixed-style path, that
-is, a Windows path with forward slashes:
-
-```python
-android_sdk_repository(
- name = "androidsdk",
- path = "c:/path/to/Android/sdk",
-)
-```
-
-**Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
-and tell Bazel where to find it by adding the following line to your `WORKSPACE` file:
-
-```python
-android_ndk_repository(name = "androidndk")
-```
-
-Similar to `android_sdk_repository`, the path to the Android NDK is inferred
-from the `ANDROID_NDK_HOME` environment variable by default. The path can also
-be explicitly specified with a `path` attribute on `android_ndk_repository`.
-
-For more information, read [Using the Android Native Development Kit with
-Bazel](/docs/android-ndk).
-
-`api_level` is the version of the Android API that the SDK and NDK
-target - for example, 23 for Android 6.0 and 25 for Android 7.1. If not
-explicitly set, `api_level` defaults to the highest available API level for
-`android_sdk_repository` and `android_ndk_repository`.
-
-It's not necessary to set the API levels to the same value for the SDK and NDK.
-[This page](https://developer.android.com/ndk/guides/stable_apis.html)
-contains a map from Android releases to NDK-supported API levels.
-
-### Create a BUILD file
-
-A [`BUILD` file](/concepts/build-files) describes the relationship
-between a set of build outputs, like compiled Android resources from `aapt` or
-class files from `javac`, and their dependencies. These dependencies may be
-source files (Java, C++) in your workspace or other build outputs. `BUILD` files
-are written in a language called **Starlark**.
-
-`BUILD` files are part of a concept in Bazel known as the *package hierarchy*.
-The package hierarchy is a logical structure that overlays the directory
-structure in your workspace. Each [package](/concepts/build-ref#packages) is a
-directory (and its subdirectories) that contains a related set of source files
-and a `BUILD` file. The package also includes any subdirectories, excluding
-those that contain their own `BUILD` file. The *package name* is the path to the
-`BUILD` file relative to the `WORKSPACE`.
-
-Note that Bazel's package hierarchy is conceptually different from the Java
-package hierarchy of your Android App directory where the `BUILD` file is
-located, although the directories may be organized identically.
-
-For the simple Android app in this tutorial, the source files in `src/main/`
-comprise a single Bazel package. A more complex project may have many nested
-packages.
-
-#### Add an android_library rule
-
-A `BUILD` file contains several different types of declarations for Bazel. The
-most important type is the
-[build rule](/concepts/build-files#types-of-build-rules), which tells
-Bazel how to build an intermediate or final software output from a set of source
-files or other dependencies. Bazel provides two build rules,
-[`android_library`](/reference/be/android#android_library) and
-[`android_binary`](/reference/be/android#android_binary), that you can use to
-build an Android app.
-
-For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
-from the app source code and resource files. You'll then use the
-`android_binary` rule to tell Bazel how to build the Android application package.
-
-Create a new `BUILD` file in the `src/main/java/com/example/bazel` directory,
-and declare a new `android_library` target:
-
-`src/main/java/com/example/bazel/BUILD`:
-
-```python
-package(
- default_visibility = ["//src:__subpackages__"],
-)
-
-android_library(
- name = "greeter_activity",
- srcs = [
- "Greeter.java",
- "MainActivity.java",
- ],
- manifest = "AndroidManifest.xml",
- resource_files = glob(["res/**"]),
-)
-```
-
-The `android_library` build rule contains a set of attributes that specify the
-information that Bazel needs to build a library module from the source files.
-Note also that the name of the rule is `greeter_activity`. You'll reference the
-rule using this name as a dependency in the `android_binary` rule.
-
-#### Add an android_binary rule
-
-The [`android_binary`](/reference/be/android#android_binary) rule builds
-the Android application package (`.apk` file) for your app.
-
-Create a new `BUILD` file in the `src/main/` directory,
-and declare a new `android_binary` target:
-
-`src/main/BUILD`:
-
-```python
-android_binary(
- name = "app",
- manifest = "AndroidManifest.xml",
- deps = ["//src/main/java/com/example/bazel:greeter_activity"],
-)
-```
-
-Here, the `deps` attribute references the output of the `greeter_activity` rule
-you added to the `BUILD` file above. This means that when Bazel builds the
-output of this rule it checks first to see if the output of the
-`greeter_activity` library rule has been built and is up-to-date. If not, Bazel
-builds it and then uses that output to build the application package file.
-
-Now, save and close the file.
-
-### Build the app
-
-Try building the app! Run the following command to build the
-`android_binary` target:
-
-```posix-terminal
-bazel build //src/main:app
-```
-
-The [`build`](/docs/user-manual#build) subcommand instructs Bazel to build the
-target that follows. The target is specified as the name of a build rule inside
-a `BUILD` file, with along with the package path relative to your workspace
-directory. For this example, the target is `app` and the package path is
-`//src/main/`.
-
-Note that you can sometimes omit the package path or target name, depending on
-your current working directory at the command line and the name of the target.
-For more details about target labels and paths, see [Labels](/concepts/labels).
-
-Bazel will start to build the sample app. During the build process, its output
-will appear similar to the following:
-
-```bash
-INFO: Analysed target //src/main:app (0 packages loaded, 0 targets configured).
-INFO: Found 1 target...
-Target //src/main:app up-to-date:
- bazel-bin/src/main/app_deploy.jar
- bazel-bin/src/main/app_unsigned.apk
- bazel-bin/src/main/app.apk
-```
-
-#### Locate the build outputs
-
-Bazel puts the outputs of both intermediate and final build operations in a set
-of per-user, per-workspace output directories. These directories are symlinked
-from the following locations at the top-level of the project directory, where
-the `WORKSPACE` is:
-
-* `bazel-bin` stores binary executables and other runnable build outputs
-* `bazel-genfiles` stores intermediary source files that are generated by
- Bazel rules
-* `bazel-out` stores other types of build outputs
-
-Bazel stores the Android `.apk` file generated using the `android_binary` rule
-in the `bazel-bin/src/main` directory, where the subdirectory name `src/main` is
-derived from the name of the Bazel package.
-
-At a command prompt, list the contents of this directory and find the `app.apk`
-file:
-
-| OS | Command |
-| ------------------------ | ------------------------ |
-| Linux, macOS | `ls bazel-bin/src/main` |
-| Windows (Command Prompt) | `dir bazel-bin\src\main` |
-| Windows (PowerShell) | `ls bazel-bin\src\main` |
-
-
-### Run the app
-
-You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/docs/user-manual#mobile-install) command. This command uses
-the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
-can also choose to install the app on the Android emulator included in Android
-Studio. Make sure the emulator is running before executing the command below.
-
-Enter the following:
-
-```posix-terminal
-bazel mobile-install //src/main:app
-```
-
-Next, find and launch the "Bazel Tutorial App":
-
-
-
-**Figure 2.** Bazel tutorial app.
-
-**Congratulations! You have just installed your first Bazel-built Android app.**
-
-Note that the `mobile-install` subcommand also supports the
-[`--incremental`](/docs/user-manual#mobile-install) flag that can be used to
-deploy only those parts of the app that have changed since the last deployment.
-
-It also supports the `--start_app` flag to start the app immediately upon
-installing it.
-
-## Further reading
-
-For more details, see these pages:
-
-* Open issues on [GitHub](https://github.com/bazelbuild/bazel/issues)
-* More information on [mobile-install](/docs/mobile-install)
-* Integrate external dependencies like AppCompat, Guava and JUnit from Maven
- repositories using [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external)
-* Run Robolectric tests with the [robolectric-bazel](https://github.com/robolectric/robolectric-bazel)
- integration.
-* Testing your app with [Android instrumentation tests](/docs/android-instrumentation-test)
-* Integrating C and C++ code into your Android app with the [NDK](/docs/android-ndk)
-* See more Bazel example projects of:
- * [a Kotlin app](https://github.com/bazelbuild/rules_jvm_external/tree/master/examples/android_kotlin_app)
- * [Robolectric testing](https://github.com/bazelbuild/rules_jvm_external/tree/master/examples/android_local_test)
- * [Espresso testing](https://github.com/bazelbuild/rules_jvm_external/tree/master/examples/android_instrumentation_test)
-
-Happy building!
diff --git a/6.5.0/start/cpp.mdx b/6.5.0/start/cpp.mdx
deleted file mode 100644
index cb81696..0000000
--- a/6.5.0/start/cpp.mdx
+++ /dev/null
@@ -1,406 +0,0 @@
----
-title: 'Bazel Tutorial: Build a C++ Project'
----
-
-
-## Introduction
-
-New to Bazel? You’re in the right place. Follow this First Build tutorial for a
-simplified introduction to using Bazel. This tutorial defines key terms as they
-are used in Bazel’s context and walks you through the basics of the Bazel
-workflow. Starting with the tools you need, you will build and run three
-projects with increasing complexity and learn how and why they get more complex.
-
-While Bazel is a [build system](https://bazel.build/basics/build-systems) that
-supports multi-language builds, this tutorial uses a C++ project as an example
-and provides the general guidelines and flow that apply to most languages.
-
-Estimated completion time: 30 minutes.
-
-### Prerequisites
-
-Start by [installing Bazel](https://bazel.build/install), if you haven’t
-already. This tutorial uses Git for source control, so for best results
-[install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as
-well.
-
-Next, retrieve the sample project from Bazel's GitHub repository by running the
-following in your command-line tool of choice:
-
-```posix-terminal
-git clone https://github.com/bazelbuild/examples
-```
-
-The sample project for this tutorial is in the `examples/cpp-tutorial` directory.
-
-Take a look below at how it’s structured:
-
-```
-examples
-└── cpp-tutorial
- ├──stage1
- │ ├── main
- │ │ ├── BUILD
- │ │ └── hello-world.cc
- │ └── WORKSPACE
- ├──stage2
- │ ├── main
- │ │ ├── BUILD
- │ │ ├── hello-world.cc
- │ │ ├── hello-greet.cc
- │ │ └── hello-greet.h
- │ └── WORKSPACE
- └──stage3
- ├── main
- │ ├── BUILD
- │ ├── hello-world.cc
- │ ├── hello-greet.cc
- │ └── hello-greet.h
- ├── lib
- │ ├── BUILD
- │ ├── hello-time.cc
- │ └── hello-time.h
- └── WORKSPACE
-```
-
-There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
-you will build both a binary and a library from a single package. In
-the third and final stage, you will build a project with multiple packages and
-build it with multiple targets.
-
-### Summary: Introduction
-
-By installing Bazel (and Git) and cloning the repository for this tutorial, you
-have laid the foundation for your first build with Bazel. Continue to the next
-section to define some terms and set up your [workspace](https://bazel.build/reference/glossary#workspace).
-
-## Getting started
-
-### Set up the workspace
-
- Before you can build a project, you need to set up its workspace. A workspace is
-a directory that holds your project's source files and Bazel's build outputs. It
-also contains these significant files:
-
-* The [`WORKSPACE` file](https://bazel.build/reference/glossary#workspace-file)
-, which identifies the directory and its contents as a Bazel workspace and
-lives at the root of the project's directory structure.
-* One or more [`BUILD` files](https://bazel.build/reference/glossary#build-file)
-, which tell Bazel how to build different parts of the project. A
-directory within the workspace that contains a BUILD file is a
-[package](https://bazel.build/reference/glossary#package). (More on packages
-later in this tutorial.)
-
-In future projects, to designate a directory as a Bazel workspace, create an
-empty file named `WORKSPACE` in that directory. For the purposes of this tutorial,
-a `WORKSPACE` file is already present in each stage.
-
-**NOTE**: When Bazel builds the project, all inputs must be in
-the same workspace. Files residing in different workspaces are independent of
-one another unless linked. More detailed information about workspace rules can
-be found in [this guide](https://bazel.build/reference/be/workspace).
-
-
-### Understand the BUILD file
-
-
-A `BUILD` file contains several different types of instructions for Bazel. Each
-`BUILD` file requires at least one [rule](https://bazel.build/reference/glossary#rule)
-as a set of instructions, which tells Bazel how to build the desired outputs,
-such as executable binaries or libraries. Each instance of a build rule in the
-`BUILD` file is called a [target](https://bazel.build/reference/glossary#target)
-and points to a specific set of source files and [dependencies](https://bazel.build/reference/glossary#dependency).
-A target can also point to other targets.
-
-Take a look at the `BUILD` file in the `cpp-tutorial/stage1/main` directory:
-
-```
-cc_binary(
- name = "hello-world",
- srcs = ["hello-world.cc"],
-)
-```
-
-In our example, the `hello-world` target instantiates Bazel's built-in
-[cc_binary rule](https://bazel.build/reference/be/c-cpp#cc_binary).
-The rule tells Bazel to build a self-contained executable binary from the
-hello-world.cc source file with no dependencies.
-
-### Summary: getting started
-
-Now you are familiar with some key terms, and what they mean in the context of
-this project and Bazel in general. In the next section, you will build and test
-Stage 1 of the project.
-
-
-## Stage 1: single target, single package
-
-It’s time to build the first part of the project. For a visual reference, the
-structure of the Stage 1 section of the project is:
-
-```
-examples
-└── cpp-tutorial
- └──stage1
- ├── main
- │ ├── BUILD
- │ └── hello-world.cc
- └── WORKSPACE
-```
-
-Run the following to move to the `cpp-tutorial/stage1` directory:
-
-```posix-terminal
-cd cpp-tutorial/stage1
-```
-
-Next, run:
-
-```posix-terminal
-bazel build //main:hello-world
-```
-
-In the target label, the `//main:` part is the location of the `BUILD` file
-relative to the root of the workspace, and `hello-world` is the target name in
-the `BUILD` file.
-
-Bazel produces something that looks like this:
-
-```
-INFO: Found 1 target...
-Target //main:hello-world up-to-date:
- bazel-bin/main/hello-world
-INFO: Elapsed time: 2.267s, Critical Path: 0.25s
-```
-
-You just built your first Bazel target. Bazel places build outputs in the
-`bazel-bin` directory at the root of the
-workspace.
-
-Now test your freshly built binary, which is:
-
-```posix-terminal
-bazel-bin/main/hello-world
-```
-
-This results in a printed “`Hello world`” message.
-
-Here’s the dependency graph of Stage 1:
-
-![Dependency graph for hello-world displays a single target with a single source file.]
-(/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays
-a single target with a single source file.")
-
-
-### Summary: stage 1
-
-Now that you have completed your first build, you have a basic idea of how a build
-is structured. In the next stage, you will add complexity by adding another
-target.
-
-## Stage 2: multiple build targets
-
-While a single target is sufficient for small projects, you may want to split
-larger projects into multiple targets and packages. This allows for fast
-incremental builds – that is, Bazel only rebuilds what's changed – and speeds up your
-builds by building multiple parts of a project at once. This stage of the
-tutorial adds a target, and the next adds a package.
-
-This is the directory you are working with for Stage 2:
-
-```
- ├──stage2
- │ ├── main
- │ │ ├── BUILD
- │ │ ├── hello-world.cc
- │ │ ├── hello-greet.cc
- │ │ └── hello-greet.h
- │ └── WORKSPACE
-```
-
-Take a look below at the `BUILD` file in the `cpp-tutorial/stage2/main` directory:
-
-```
-cc_library(
- name = "hello-greet",
- srcs = ["hello-greet.cc"],
- hdrs = ["hello-greet.h"],
-)
-
-cc_binary(
- name = "hello-world",
- srcs = ["hello-world.cc"],
- deps = [
- ":hello-greet",
- ],
-)
-```
-
-With this `BUILD` file, Bazel first builds the `hello-greet` library
-(using Bazel's built-in [cc_library rule](https://bazel.build/reference/be/c-cpp#cc_library)),
-then the hello-world binary. The deps attribute in
-the hello-world target tells Bazel that the hello-greet
-library is required to build the hello-world binary.
-
-Before you can build this new version of the project, you need to change
-directories, switching to the `cpp-tutorial/stage2` directory by running:
-
-```posix-terminal
-cd ../stage2
-```
-
-Now you can build the new binary using the following familiar command:
-
-```posix-terminal
-bazel build //main:hello-world
-```
-
-Once again, Bazel produces something that looks like this:
-
-```
-INFO: Found 1 target...
-Target //main:hello-world up-to-date:
- bazel-bin/main/hello-world
-INFO: Elapsed time: 2.399s, Critical Path: 0.30s
-```
-
-Now you can test your freshly built binary, which returns another “`Hello world`”:
-
-```posix-terminal
-bazel-bin/main/hello-world
-```
-
-If you now modify `hello-greet.cc` and rebuild the project, Bazel only recompiles
-that file.
-
-Looking at the dependency graph, you can see that hello-world depends on the
-same inputs as it did before, but the structure of the build is different:
-
-
-
-### Summary: stage 2
-
-You've now built the project with two targets. The `hello-world` target builds
-one source file and depends on one other target (`//main:hello-greet`), which
-builds two additional source files. In the next section, take it a step further
-and add another package.
-
-## Stage 3: multiple packages
-
-This next stage adds another layer of complication and builds a project with
-multiple packages. Take a look below at the structure and contents of the
-`cpp-tutorial/stage3` directory:
-
-```
-└──stage3
- ├── main
- │ ├── BUILD
- │ ├── hello-world.cc
- │ ├── hello-greet.cc
- │ └── hello-greet.h
- ├── lib
- │ ├── BUILD
- │ ├── hello-time.cc
- │ └── hello-time.h
- └── WORKSPACE
-```
-
-You can see that now there are two sub-directories, and each contains a `BUILD`
-file. Therefore, to Bazel, the workspace now contains two packages: `lib` and
-`main`.
-
-Take a look at the `lib/BUILD` file:
-
-```
-cc_library(
- name = "hello-time",
- srcs = ["hello-time.cc"],
- hdrs = ["hello-time.h"],
- visibility = ["//main:__pkg__"],
-)
-```
-
-And at the `main/BUILD` file:
-
-```
-cc_library(
- name = "hello-greet",
- srcs = ["hello-greet.cc"],
- hdrs = ["hello-greet.h"],
-)
-
-cc_binary(
- name = "hello-world",
- srcs = ["hello-world.cc"],
- deps = [
- ":hello-greet",
- "//lib:hello-time",
- ],
-)
-```
-
-The `hello-world` target in the main package depends on the` hello-time` target
-in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
-this through the `deps` attribute. You can see this reflected in the dependency
-graph:
-
-
-
-For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
-explicitly visible to targets in `main/BUILD` using the visibility attribute.
-This is because by default targets are only visible to other targets in the same
-`BUILD` file. Bazel uses target visibility to prevent issues such as libraries
-containing implementation details leaking into public APIs.
-
-Now build this final version of the project. Switch to the `cpp-tutorial/stage3`
-directory by running:
-
-```posix-terminal
-cd ../stage3
-```
-
-Once again, run the following command:
-
-```posix-terminal
-bazel build //main:hello-world
-```
-
-Bazel produces something that looks like this:
-
-```
-INFO: Found 1 target...
-Target //main:hello-world up-to-date:
- bazel-bin/main/hello-world
-INFO: Elapsed time: 0.167s, Critical Path: 0.00s
-```
-
-Now test the last binary of this tutorial for a final `Hello world` message:
-
-```posix-terminal
-bazel-bin/main/hello-world
-```
-
-### Summary: stage 3
-
-You've now built the project as two packages with three targets and understand
-the dependencies between them, which equips you to go forth and build future
-projects with Bazel. In the next section, take a look at how to continue your
-Bazel journey.
-
-## Next steps
-
-You’ve now completed your first basic build with Bazel, but this is just the
-start. Here are some more resources to continue learning with Bazel:
-
-* To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/tutorials/cpp-use-cases).
-* To get started with building other applications with Bazel, see the tutorials
-for [Java](https://bazel.build/tutorials/java), [Android application](https://bazel.build/tutorials/android-app),
-or [iOS application](https://bazel.build/tutorials/ios-app).
-* To learn more about working with local and remote repositories, read about
-[external dependencies](https://bazel.build/docs/external).
-* To learn more about Bazel’s other rules, see this [reference guide](https://bazel.build/rules).
-
-Happy building!
diff --git a/6.5.0/start/ios-app.mdx b/6.5.0/start/ios-app.mdx
deleted file mode 100644
index a46b8dc..0000000
--- a/6.5.0/start/ios-app.mdx
+++ /dev/null
@@ -1,361 +0,0 @@
----
-title: 'Bazel Tutorial: Build an iOS App'
----
-
-
-This tutorial covers how to build a simple iOS app using Bazel.
-
-## What you'll learn
-
-In this tutorial, you learn how to:
-
-* Set up the environment by installing Bazel and Xcode, and downloading the
- sample project
-* Set up a Bazel [workspace](/concepts/build-ref#workspace) that contained the source code
- for the app and a `WORKSPACE` file that identifies the top level of the
- workspace directory
-* Update the `WORKSPACE` file to contain references to the required
- external dependencies
-* Create a `BUILD` file
-* Run Bazel to build the app for the simulator and an iOS device
-* Run the app in the simulator and on an iOS device
-
-## Set up your environment
-
-To get started, install Bazel and Xcode, and get the sample project.
-
-### Install Bazel
-
-Follow the [installation instructions](/install/) to install Bazel and
-its dependencies.
-
-### Install Xcode
-
-Download and install [Xcode](https://developer.apple.com/xcode/downloads/).
-Xcode contains the compilers, SDKs, and other tools required by Bazel to build
-Apple applications.
-
-### Get the sample project
-
-You also need to get the sample project for the tutorial from GitHub. The GitHub
-repo has two branches: `source-only` and `main`. The `source-only` branch
-contains the source files for the project only. You'll use the files in this
-branch in this tutorial. The `main` branch contains both the source files
-and completed Bazel `WORKSPACE` and `BUILD` files. You can use the files in this
-branch to check your work when you've completed the tutorial steps.
-
-Enter the following at the command line to get the files in the `source-only`
-branch:
-
-```bash
-cd $HOME
-git clone -b source-only https://github.com/bazelbuild/examples
-```
-
-The `git clone` command creates a directory named `$HOME/examples/`. This
-directory contains several sample projects for Bazel. The project files for this
-tutorial are in `$HOME/examples/tutorial/ios-app`.
-
-## Set up a workspace
-
-A [workspace](/concepts/build-ref#workspace) is a directory that contains the
-source files for one or more software projects, as well as a `WORKSPACE` file
-and `BUILD` files that contain the instructions that Bazel uses to build
-the software. The workspace may also contain symbolic links to output
-directories.
-
-A workspace directory can be located anywhere on your filesystem and is denoted
-by the presence of the `WORKSPACE` file at its root. In this tutorial, your
-workspace directory is `$HOME/examples/tutorial/`, which contains the sample
-project files you cloned from the GitHub repo in the previous step.
-
-Note: Bazel itself doesn't impose any requirements for organizing source
-files in your workspace. The sample source files in this tutorial are organized
-according to conventions for the target platform.
-
-For your convenience, set the `$WORKSPACE` environment variable now to refer to
-your workspace directory. At the command line, enter:
-
-```bash
-export WORKSPACE=$HOME/examples/tutorial
-```
-
-### Create a WORKSPACE file
-
-Every workspace must have a text file named `WORKSPACE` located in the top-level
-workspace directory. This file may be empty or it may contain references
-to [external dependencies](/docs/external) required to build the
-software.
-
-For now, you'll create an empty `WORKSPACE` file, which simply serves to
-identify the workspace directory. In later steps, you'll update the file to add
-external dependency information.
-
-Enter the following at the command line:
-
-```bash
-touch $WORKSPACE/WORKSPACE
-open -a Xcode $WORKSPACE/WORKSPACE
-```
-
-This creates and opens the empty `WORKSPACE` file.
-
-### Update the WORKSPACE file
-
-To build applications for Apple devices, Bazel needs to pull the latest
-[Apple build rules](https://github.com/bazelbuild/rules_apple)
-from its GitHub repository. To enable this, add the following
-[`git_repository`](/reference/be/workspace#git_repository)
-rules to your `WORKSPACE` file:
-
-```python
-load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
-
-git_repository(
- name = "build_bazel_rules_apple",
- remote = "https://github.com/bazelbuild/rules_apple.git",
- tag = "0.19.0",
-)
-
-git_repository(
- name = "build_bazel_rules_swift",
- remote = "https://github.com/bazelbuild/rules_swift.git",
- tag = "0.13.0",
-)
-
-git_repository(
- name = "build_bazel_apple_support",
- remote = "https://github.com/bazelbuild/apple_support.git",
- tag = "0.7.2",
-)
-
-git_repository(
- name = "bazel_skylib",
- remote = "https://github.com/bazelbuild/bazel-skylib.git",
- tag = "0.9.0",
-)
-```
-
-Note: "Always use the
-[latest version of the build_apple rules](https://github.com/bazelbuild/rules_apple/releases)
-in the `tag` attribute. Make sure to check the latest dependencies required in
-`rules_apple`'s [project](https://github.com/bazelbuild/rules_apple)."
-
-Note: You **must** set the value of the `name` attribute in the
-`git_repository` rule to `build_bazel_rules_apple` or the build will fail.
-
-## Review the source files
-
-Take a look at the source files for the app located in
-`$WORKSPACE/ios-app/UrlGet`. Again, you're just looking at these files now to
-become familiar with the structure of the app. You don't have to edit any of the
-source files to complete this tutorial.
-
-## Create a BUILD file
-
-At a command-line prompt, open a new `BUILD` file for editing:
-
-```bash
-touch $WORKSPACE/ios-app/BUILD
-open -a Xcode $WORKSPACE/ios-app/BUILD
-```
-
-### Add the rule load statement
-
-To build iOS targets, Bazel needs to load build rules from its GitHub repository
-whenever the build runs. To make these rules available to your project, add the
-following load statement to the beginning of your `BUILD` file:
-
-```
-load("@build_bazel_rules_apple//apple:ios.bzl", "ios_application")
-```
-
-You only need to load the `ios_application` rule because the `objc_library`
-rule is built into the Bazel package.
-
-### Add an objc_library rule
-
-Bazel provides several build rules that you can use to build an app for the
-iOS platform. For this tutorial, you'll first use the
-[`objc_library`](/reference/be/objective-c#objc_library) rule to tell Bazel
-how to build a static library from the app source code and Xib files. Then
-you'll use the
-[`ios_application`](https://github.com/bazelbuild/rules_apple/tree/main/doc)
-rule to tell it how to build the application binary and the `.ipa` bundle.
-
-Note: This tutorial presents a minimal use case of the Objective-C rules in
-Bazel. For example, you have to use the `ios_application` rule to build
-multi-architecture iOS apps.
-
-Add the following to your `BUILD` file:
-
-```python
-objc_library(
- name = "UrlGetClasses",
- srcs = [
- "UrlGet/AppDelegate.m",
- "UrlGet/UrlGetViewController.m",
- "UrlGet/main.m",
- ],
- hdrs = glob(["UrlGet/*.h"]),
- data = ["UrlGet/UrlGetViewController.xib"],
-)
-```
-
-Note the name of the rule, `UrlGetClasses`.
-
-### Add an ios_application rule
-
-The
-[`ios_application`](https://github.com/bazelbuild/rules_apple/tree/main/doc)
-rule builds the application binary and creates the `.ipa` bundle file.
-
-Add the following to your `BUILD` file:
-
-```python
-ios_application(
- name = "ios-app",
- bundle_id = "Google.UrlGet",
- families = [
- "iphone",
- "ipad",
- ],
- minimum_os_version = "9.0",
- infoplists = [":UrlGet/UrlGet-Info.plist"],
- visibility = ["//visibility:public"],
- deps = [":UrlGetClasses"],
-)
-```
-
-Note: Please update the `minimum_os_version` attribute to the minimum
-version of iOS that you plan to support.
-
-Note how the `deps` attribute references the output of the `UrlGetClasses` rule
-you added to the `BUILD` file above.
-
-Now, save and close the file. You can compare your `BUILD` file to the
-[completed example](https://github.com/bazelbuild/examples/blob/main/tutorial/ios-app/BUILD)
-in the `main` branch of the GitHub repo.
-
-## Build and deploy the app
-
-You are now ready to build your app and deploy it to a simulator and onto an
-iOS device.
-
-Note: The app launches standalone but requires a backend server in order to
-produce output. See the README file in the sample project directory to find out
-how to build the backend server.
-
-The built app is located in the `$WORKSPACE/bazel-bin` directory.
-
-Completed `WORKSPACE` and `BUILD` files for this tutorial are located in the
-[main branch](https://github.com/bazelbuild/examples/tree/main/tutorial)
-of the GitHub repo. You can compare your work to the completed files for
-additional help or troubleshooting.
-
-### Build the app for the simulator
-
-Make sure that your current working directory is inside your Bazel workspace:
-
-```bash
-cd $WORKSPACE
-```
-
-Now, enter the following to build the sample app:
-
-```bash
-bazel build //ios-app:ios-app
-```
-
-Bazel launches and builds the sample app. During the build process, its
-output will appear similar to the following:
-
-```bash
-INFO: Found 1 target...
-Target //ios-app:ios-app up-to-date:
- bazel-bin/ios-app/ios-app.ipa
-INFO: Elapsed time: 0.565s, Critical Path: 0.44s
-```
-
-### Find the build outputs
-
-The `.ipa` file and other outputs are located in the
-`$WORKSPACE/bazel-bin/ios-app` directory.
-
-### Run and debug the app in the simulator
-
-You can now run the app from Xcode using the iOS Simulator. First,
-[generate an Xcode project using Tulsi](http://tulsi.bazel.build/).
-
-Then, open the project in Xcode, choose an iOS Simulator as the runtime scheme,
-and click **Run**.
-
-Note: If you modify any project files in Xcode (for example, if you add or
-remove a file, or add or change a dependency), you must rebuild the app using
-Bazel, re-generate the Xcode project in Tulsi, and then re-open the project in
-Xcode.
-
-### Build the app for a device
-
-To build your app so that it installs and launches on an iOS device, Bazel needs
-the appropriate provisioning profile for that device model. Do the following:
-
-1. Go to your [Apple Developer Account](https://developer.apple.com/account)
- and download the appropriate provisioning profile for your device. See
- [Apple's documentation](https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/MaintainingProfiles/MaintainingProfiles.html)
- for more information.
-
-2. Move your profile into `$WORKSPACE`.
-
-3. (Optional) Add your profile to your `.gitignore` file.
-
-4. Add the following line to the `ios_application` target in your `BUILD` file:
-
- ```python
- provisioning_profile = "| Command | -deps = | -
bazel build //myapp:mybinary --cpu=arm |
- [":arm_lib"] |
-
bazel build //myapp:mybinary -c dbg --cpu=x86 |
- [":x86_dev_lib"] |
-
bazel build //myapp:mybinary --cpu=ppc |
- [":generic_lib"] |
-
bazel build //myapp:mybinary -c dbg --cpu=ppc |
- [":generic_lib"] |
-
| Command | -deps = | -
bazel build //myapp:mybinary --cpu=arm |
- [":arm_lib"] |
-
bazel build //myapp:mybinary -c dbg --cpu=x86 |
- [":x86_dev_lib"] |
-
bazel build //myapp:mybinary --cpu=ppc |
- [":generic_lib"] |
-
bazel build //myapp:mybinary -c dbg --cpu=ppc |
- [":generic_lib"] |
-
-
-This works, because Bazel will always run the validation action when the compile
-action is run, but this has significant drawbacks:
-
-1. The validation action is in the critical path of the build. Because Bazel
-thinks the empty output is required to run the compile action, it will run the
-validation action first, even though the compile action will ignore the input.
-This reduces parallelism and slows down builds.
-
-2. If other actions in the build might run instead of the
-compile action, then the empty outputs of validation actions need to be added to
-those actions as well (`java_library`'s source jar output, for example). This is
-also a problem if new actions that might run instead of the compile action are
-added later, and the empty validation output is accidentally left off.
-
-The solution to these problems is to use the Validations Output Group.
-
-#### Validations Output Group
-
-The Validations Output Group is an output group designed to hold the otherwise
-unused outputs of validation actions, so that they don't need to be artificially
-added to the inputs of other actions.
-
-This group is special in that its outputs are always requested, regardless of
-the value of the `--output_groups` flag, and regardless of how the target is
-depended upon (for example, on the command line, as a dependency, or through
-implicit outputs of the target). Note that normal caching and incrementality
-still apply: if the inputs to the validation action have not changed and the
-validation action previously succeeded, then the validation action will not be
-run.
-
-
-
-Using this output group still requires that validation actions output some file,
-even an empty one. This might require wrapping some tools that normally don't
-create outputs so that a file is created.
-
-A target's validation actions are not run in three cases:
-
-* When the target is depended upon as a tool
-* When the target is depended upon as an implicit dependency (for example, an
- attribute that starts with "_")
-* When the target is built in the host or exec configuration.
-
-It is assumed that these targets have their own
-separate builds and tests that would uncover any validation failures.
-
-#### Using the Validations Output Group
-
-The Validations Output Group is named `_validation` and is used like any other
-output group:
-
-```python
-def _rule_with_validation_impl(ctx):
-
- ctx.actions.write(ctx.outputs.main, "main output\n")
-
- ctx.actions.write(ctx.outputs.implicit, "implicit output\n")
-
- validation_output = ctx.actions.declare_file(ctx.attr.name + ".validation")
- ctx.actions.run(
- outputs = [validation_output],
- executable = ctx.executable._validation_tool,
- arguments = [validation_output.path])
-
- return [
- DefaultInfo(files = depset([ctx.outputs.main])),
- OutputGroupInfo(_validation = depset([validation_output])),
- ]
-
-
-rule_with_validation = rule(
- implementation = _rule_with_validation_impl,
- outputs = {
- "main": "%{name}.main",
- "implicit": "%{name}.implicit",
- },
- attrs = {
- "_validation_tool": attr.label(
- default = Label("//validation_actions:validation_tool"),
- executable = True,
- cfg = "exec"),
- }
-)
-```
-
-Notice that the validation output file is not added to the `DefaultInfo` or the
-inputs to any other action. The validation action for a target of this rule kind
-will still run if the target is depended upon by label, or any of the target's
-implicit outputs are directly or indirectly depended upon.
-
-It is usually important that the outputs of validation actions only go into the
-validation output group, and are not added to the inputs of other actions, as
-this could defeat parallelism gains. Note however that Bazel does not currently
-have any special checking to enforce this. Therefore, you should test
-that validation action outputs are not added to the inputs of any actions in the
-tests for Starlark rules. For example:
-
-```python
-load("@bazel_skylib//lib:unittest.bzl", "analysistest")
-
-def _validation_outputs_test_impl(ctx):
- env = analysistest.begin(ctx)
-
- actions = analysistest.target_actions(env)
- target = analysistest.target_under_test(env)
- validation_outputs = target.output_groups._validation.to_list()
- for action in actions:
- for validation_output in validation_outputs:
- if validation_output in action.inputs.to_list():
- analysistest.fail(env,
- "%s is a validation action output, but is an input to action %s" % (
- validation_output, action))
-
- return analysistest.end(env)
-
-validation_outputs_test = analysistest.make(_validation_outputs_test_impl)
-```
-
-#### Validation Actions Flag
-
-Running validation actions is controlled by the `--run_validations` command line
-flag, which defaults to true.
-
-## Deprecated features
-
-### Deprecated predeclared outputs
-
-There are two **deprecated** ways of using predeclared outputs:
-
-* The [`outputs`](/rules/lib/globals/bzl#rule.outputs) parameter of `rule` specifies
- a mapping between output attribute names and string templates for generating
- predeclared output labels. Prefer using non-predeclared outputs and
- explicitly adding outputs to `DefaultInfo.files`. Use the rule target's
- label as input for rules which consume the output instead of a predeclared
- output's label.
-
-* For [executable rules](#executable-rules), `ctx.outputs.executable` refers
- to a predeclared executable output with the same name as the rule target.
- Prefer declaring the output explicitly, for example with
- `ctx.actions.declare_file(ctx.label.name)`, and ensure that the command that
- generates the executable sets its permissions to allow execution. Explicitly
- pass the executable output to the `executable` parameter of `DefaultInfo`.
-
-### Runfiles features to avoid
-
-[`ctx.runfiles`](/rules/lib/builtins/ctx#runfiles) and the [`runfiles`](/rules/lib/builtins/runfiles)
-type have a complex set of features, many of which are kept for legacy reasons.
-The following recommendations help reduce complexity:
-
-* **Avoid** use of the `collect_data` and `collect_default` modes of
- [`ctx.runfiles`](/rules/lib/builtins/ctx#runfiles). These modes implicitly collect
- runfiles across certain hardcoded dependency edges in confusing ways.
- Instead, add files using the `files` or `transitive_files` parameters of
- `ctx.runfiles`, or by merging in runfiles from dependencies with
- `runfiles = runfiles.merge(dep[DefaultInfo].default_runfiles)`.
-
-* **Avoid** use of the `data_runfiles` and `default_runfiles` of the
- `DefaultInfo` constructor. Specify `DefaultInfo(runfiles = ...)` instead.
- The distinction between "default" and "data" runfiles is maintained for
- legacy reasons. For example, some rules put their default outputs in
- `data_runfiles`, but not `default_runfiles`. Instead of using
- `data_runfiles`, rules should *both* include default outputs and merge in
- `default_runfiles` from attributes which provide runfiles (often
- [`data`](/reference/be/common-definitions#common-attributes.data)).
-
-* When retrieving `runfiles` from `DefaultInfo` (generally only for merging
- runfiles between the current rule and its dependencies), use
- `DefaultInfo.default_runfiles`, **not** `DefaultInfo.data_runfiles`.
-
-### Migrating from legacy providers
-
-Historically, Bazel providers were simple fields on the `Target` object. They
-were accessed using the dot operator, and they were created by putting the field
-in a struct returned by the rule's implementation function.
-
-*This style is deprecated and should not be used in new code;* see below for
-information that may help you migrate. The new provider mechanism avoids name
-clashes. It also supports data hiding, by requiring any code accessing a
-provider instance to retrieve it using the provider symbol.
-
-For the moment, legacy providers are still supported. A rule can return both
-legacy and modern providers as follows:
-
-```python
-def _old_rule_impl(ctx):
- ...
- legacy_data = struct(x="foo", ...)
- modern_data = MyInfo(y="bar", ...)
- # When any legacy providers are returned, the top-level returned value is a
- # struct.
- return struct(
- # One key = value entry for each legacy provider.
- legacy_info = legacy_data,
- ...
- # Additional modern providers:
- providers = [modern_data, ...])
-```
-
-If `dep` is the resulting `Target` object for an instance of this rule, the
-providers and their contents can be retrieved as `dep.legacy_info.x` and
-`dep[MyInfo].y`.
-
-In addition to `providers`, the returned struct can also take several other
-fields that have special meaning (and thus do not create a corresponding legacy
-provider):
-
-* The fields `files`, `runfiles`, `data_runfiles`, `default_runfiles`, and
- `executable` correspond to the same-named fields of
- [`DefaultInfo`](/rules/lib/providers/DefaultInfo). It is not allowed to specify any of
- these fields while also returning a `DefaultInfo` provider.
-
-* The field `output_groups` takes a struct value and corresponds to an
- [`OutputGroupInfo`](/rules/lib/providers/OutputGroupInfo).
-
-In [`provides`](/rules/lib/globals/bzl#rule.provides) declarations of rules, and in
-[`providers`](/rules/lib/toplevel/attr#label_list.providers) declarations of dependency
-attributes, legacy providers are passed in as strings and modern providers are
-passed in by their `*Info` symbol. Be sure to change from strings to symbols
-when migrating. For complex or large rule sets where it is difficult to update
-all rules atomically, you may have an easier time if you follow this sequence of
-steps:
-
-1. Modify the rules that produce the legacy provider to produce both the legacy
- and modern providers, using the above syntax. For rules that declare they
- return the legacy provider, update that declaration to include both the
- legacy and modern providers.
-
-2. Modify the rules that consume the legacy provider to instead consume the
- modern provider. If any attribute declarations require the legacy provider,
- also update them to instead require the modern provider. Optionally, you can
- interleave this work with step 1 by having consumers accept/require either
- provider: Test for the presence of the legacy provider using
- `hasattr(target, 'foo')`, or the new provider using `FooInfo in target`.
-
-3. Fully remove the legacy provider from all rules.
diff --git a/7.6.1/extending/toolchains.mdx b/7.6.1/extending/toolchains.mdx
deleted file mode 100644
index 972fc94..0000000
--- a/7.6.1/extending/toolchains.mdx
+++ /dev/null
@@ -1,597 +0,0 @@
----
-title: 'Toolchains'
----
-
-
-
-This page describes the toolchain framework, which is a way for rule authors to
-decouple their rule logic from platform-based selection of tools. It is
-recommended to read the [rules](/extending/rules) and [platforms](/extending/platforms)
-pages before continuing. This page covers why toolchains are needed, how to
-define and use them, and how Bazel selects an appropriate toolchain based on
-platform constraints.
-
-## Motivation
-
-Let's first look at the problem toolchains are designed to solve. Suppose you
-are writing rules to support the "bar" programming language. Your `bar_binary`
-rule would compile `*.bar` files using the `barc` compiler, a tool that itself
-is built as another target in your workspace. Since users who write `bar_binary`
-targets shouldn't have to specify a dependency on the compiler, you make it an
-implicit dependency by adding it to the rule definition as a private attribute.
-
-```python
-bar_binary = rule(
- implementation = _bar_binary_impl,
- attrs = {
- "srcs": attr.label_list(allow_files = True),
- ...
- "_compiler": attr.label(
- default = "//bar_tools:barc_linux", # the compiler running on linux
- providers = [BarcInfo],
- ),
- },
-)
-```
-
-`//bar_tools:barc_linux` is now a dependency of every `bar_binary` target, so
-it'll be built before any `bar_binary` target. It can be accessed by the rule's
-implementation function just like any other attribute:
-
-```python
-BarcInfo = provider(
- doc = "Information about how to invoke the barc compiler.",
- # In the real world, compiler_path and system_lib might hold File objects,
- # but for simplicity they are strings for this example. arch_flags is a list
- # of strings.
- fields = ["compiler_path", "system_lib", "arch_flags"],
-)
-
-def _bar_binary_impl(ctx):
- ...
- info = ctx.attr._compiler[BarcInfo]
- command = "%s -l %s %s" % (
- info.compiler_path,
- info.system_lib,
- " ".join(info.arch_flags),
- )
- ...
-```
-
-The issue here is that the compiler's label is hardcoded into `bar_binary`, yet
-different targets may need different compilers depending on what platform they
-are being built for and what platform they are being built on -- called the
-*target platform* and *execution platform*, respectively. Furthermore, the rule
-author does not necessarily even know all the available tools and platforms, so
-it is not feasible to hardcode them in the rule's definition.
-
-A less-than-ideal solution would be to shift the burden onto users, by making
-the `_compiler` attribute non-private. Then individual targets could be
-hardcoded to build for one platform or another.
-
-```python
-bar_binary(
- name = "myprog_on_linux",
- srcs = ["mysrc.bar"],
- compiler = "//bar_tools:barc_linux",
-)
-
-bar_binary(
- name = "myprog_on_windows",
- srcs = ["mysrc.bar"],
- compiler = "//bar_tools:barc_windows",
-)
-```
-
-You can improve on this solution by using `select` to choose the `compiler`
-[based on the platform](/docs/configurable-attributes):
-
-```python
-config_setting(
- name = "on_linux",
- constraint_values = [
- "@platforms//os:linux",
- ],
-)
-
-config_setting(
- name = "on_windows",
- constraint_values = [
- "@platforms//os:windows",
- ],
-)
-
-bar_binary(
- name = "myprog",
- srcs = ["mysrc.bar"],
- compiler = select({
- ":on_linux": "//bar_tools:barc_linux",
- ":on_windows": "//bar_tools:barc_windows",
- }),
-)
-```
-
-But this is tedious and a bit much to ask of every single `bar_binary` user.
-If this style is not used consistently throughout the workspace, it leads to
-builds that work fine on a single platform but fail when extended to
-multi-platform scenarios. It also does not address the problem of adding support
-for new platforms and compilers without modifying existing rules or targets.
-
-The toolchain framework solves this problem by adding an extra level of
-indirection. Essentially, you declare that your rule has an abstract dependency
-on *some* member of a family of targets (a toolchain type), and Bazel
-automatically resolves this to a particular target (a toolchain) based on the
-applicable platform constraints. Neither the rule author nor the target author
-need know the complete set of available platforms and toolchains.
-
-## Writing rules that use toolchains
-
-Under the toolchain framework, instead of having rules depend directly on tools,
-they instead depend on *toolchain types*. A toolchain type is a simple target
-that represents a class of tools that serve the same role for different
-platforms. For instance, you can declare a type that represents the bar
-compiler:
-
-```python
-# By convention, toolchain_type targets are named "toolchain_type" and
-# distinguished by their package path. So the full path for this would be
-# //bar_tools:toolchain_type.
-toolchain_type(name = "toolchain_type")
-```
-
-The rule definition in the previous section is modified so that instead of
-taking in the compiler as an attribute, it declares that it consumes a
-`//bar_tools:toolchain_type` toolchain.
-
-```python
-bar_binary = rule(
- implementation = _bar_binary_impl,
- attrs = {
- "srcs": attr.label_list(allow_files = True),
- ...
- # No `_compiler` attribute anymore.
- },
- toolchains = ["//bar_tools:toolchain_type"],
-)
-```
-
-The implementation function now accesses this dependency under `ctx.toolchains`
-instead of `ctx.attr`, using the toolchain type as the key.
-
-```python
-def _bar_binary_impl(ctx):
- ...
- info = ctx.toolchains["//bar_tools:toolchain_type"].barcinfo
- # The rest is unchanged.
- command = "%s -l %s %s" % (
- info.compiler_path,
- info.system_lib,
- " ".join(info.arch_flags),
- )
- ...
-```
-
-`ctx.toolchains["//bar_tools:toolchain_type"]` returns the
-[`ToolchainInfo` provider](/rules/lib/toplevel/platform_common#ToolchainInfo)
-of whatever target Bazel resolved the toolchain dependency to. The fields of the
-`ToolchainInfo` object are set by the underlying tool's rule; in the next
-section, this rule is defined such that there is a `barcinfo` field that wraps
-a `BarcInfo` object.
-
-Bazel's procedure for resolving toolchains to targets is described
-[below](#toolchain-resolution). Only the resolved toolchain target is actually
-made a dependency of the `bar_binary` target, not the whole space of candidate
-toolchains.
-
-### Mandatory and Optional Toolchains
-
-By default, when a rule expresses a toolchain type dependency using a bare label
-(as shown above), the toolchain type is considered to be **mandatory**. If Bazel
-is unable to find a matching toolchain (see
-[Toolchain resolution](#toolchain-resolution) below) for a mandatory toolchain
-type, this is an error and analysis halts.
-
-It is possible instead to declare an **optional** toolchain type dependency, as
-follows:
-
-```python
-bar_binary = rule(
- ...
- toolchains = [
- config_common.toolchain_type("//bar_tools:toolchain_type", mandatory = False),
- ],
-)
-```
-
-When an optional toolchain type cannot be resolved, analysis continues, and the
-result of `ctx.toolchains["//bar_tools:toolchain_type"]` is `None`.
-
-The [`config_common.toolchain_type`](/rules/lib/toplevel/config_common#toolchain_type)
-function defaults to mandatory.
-
-The following forms can be used:
-
-- Mandatory toolchain types:
- - `toolchains = ["//bar_tools:toolchain_type"]`
- - `toolchains = [config_common.toolchain_type("//bar_tools:toolchain_type")]`
- - `toolchains = [config_common.toolchain_type("//bar_tools:toolchain_type", mandatory = True)]`
-- Optional toolchain types:
- - `toolchains = [config_common.toolchain_type("//bar_tools:toolchain_type", mandatory = False)]`
-
-```python
-bar_binary = rule(
- ...
- toolchains = [
- "//foo_tools:toolchain_type",
- config_common.toolchain_type("//bar_tools:toolchain_type", mandatory = False),
- ],
-)
-```
-
-You can mix and match forms in the same rule, also. However, if the same
-toolchain type is listed multiple times, it will take the most strict version,
-where mandatory is more strict than optional.
-
-### Writing aspects that use toolchains
-
-Aspects have access to the same toolchain API as rules: you can define required
-toolchain types, access toolchains via the context, and use them to generate new
-actions using the toolchain.
-
-```py
-bar_aspect = aspect(
- implementation = _bar_aspect_impl,
- attrs = {},
- toolchains = ['//bar_tools:toolchain_type'],
-)
-
-def _bar_aspect_impl(target, ctx):
- toolchain = ctx.toolchains['//bar_tools:toolchain_type']
- # Use the toolchain provider like in a rule.
- return []
-```
-
-## Defining toolchains
-
-To define some toolchains for a given toolchain type, you need three things:
-
-1. A language-specific rule representing the kind of tool or tool suite. By
- convention this rule's name is suffixed with "\_toolchain".
-
- 1. **Note:** The `\_toolchain` rule cannot create any build actions.
- Rather, it collects artifacts from other rules and forwards them to the
- rule that uses the toolchain. That rule is responsible for creating all
- build actions.
-
-2. Several targets of this rule type, representing versions of the tool or tool
- suite for different platforms.
-
-3. For each such target, an associated target of the generic
- [`toolchain`](/reference/be/platforms-and-toolchains#toolchain)
- rule, to provide metadata used by the toolchain framework. This `toolchain`
- target also refers to the `toolchain_type` associated with this toolchain.
- This means that a given `_toolchain` rule could be associated with any
- `toolchain_type`, and that only in a `toolchain` instance that uses
- this `_toolchain` rule that the rule is associated with a `toolchain_type`.
-
-For our running example, here's a definition for a `bar_toolchain` rule. Our
-example has only a compiler, but other tools such as a linker could also be
-grouped underneath it.
-
-```python
-def _bar_toolchain_impl(ctx):
- toolchain_info = platform_common.ToolchainInfo(
- barcinfo = BarcInfo(
- compiler_path = ctx.attr.compiler_path,
- system_lib = ctx.attr.system_lib,
- arch_flags = ctx.attr.arch_flags,
- ),
- )
- return [toolchain_info]
-
-bar_toolchain = rule(
- implementation = _bar_toolchain_impl,
- attrs = {
- "compiler_path": attr.string(),
- "system_lib": attr.string(),
- "arch_flags": attr.string_list(),
- },
-)
-```
-
-The rule must return a `ToolchainInfo` provider, which becomes the object that
-the consuming rule retrieves using `ctx.toolchains` and the label of the
-toolchain type. `ToolchainInfo`, like `struct`, can hold arbitrary field-value
-pairs. The specification of exactly what fields are added to the `ToolchainInfo`
-should be clearly documented at the toolchain type. In this example, the values
-return wrapped in a `BarcInfo` object to reuse the schema defined above; this
-style may be useful for validation and code reuse.
-
-Now you can define targets for specific `barc` compilers.
-
-```python
-bar_toolchain(
- name = "barc_linux",
- arch_flags = [
- "--arch=Linux",
- "--debug_everything",
- ],
- compiler_path = "/path/to/barc/on/linux",
- system_lib = "/usr/lib/libbarc.so",
-)
-
-bar_toolchain(
- name = "barc_windows",
- arch_flags = [
- "--arch=Windows",
- # Different flags, no debug support on windows.
- ],
- compiler_path = "C:\\path\\on\\windows\\barc.exe",
- system_lib = "C:\\path\\on\\windows\\barclib.dll",
-)
-```
-
-Finally, you create `toolchain` definitions for the two `bar_toolchain` targets.
-These definitions link the language-specific targets to the toolchain type and
-provide the constraint information that tells Bazel when the toolchain is
-appropriate for a given platform.
-
-```python
-toolchain(
- name = "barc_linux_toolchain",
- exec_compatible_with = [
- "@platforms//os:linux",
- "@platforms//cpu:x86_64",
- ],
- target_compatible_with = [
- "@platforms//os:linux",
- "@platforms//cpu:x86_64",
- ],
- toolchain = ":barc_linux",
- toolchain_type = ":toolchain_type",
-)
-
-toolchain(
- name = "barc_windows_toolchain",
- exec_compatible_with = [
- "@platforms//os:windows",
- "@platforms//cpu:x86_64",
- ],
- target_compatible_with = [
- "@platforms//os:windows",
- "@platforms//cpu:x86_64",
- ],
- toolchain = ":barc_windows",
- toolchain_type = ":toolchain_type",
-)
-```
-
-The use of relative path syntax above suggests these definitions are all in the
-same package, but there's no reason the toolchain type, language-specific
-toolchain targets, and `toolchain` definition targets can't all be in separate
-packages.
-
-See the [`go_toolchain`](https://github.com/bazelbuild/rules_go/blob/master/go/private/go_toolchain.bzl)
-for a real-world example.
-
-### Toolchains and configurations
-
-An important question for rule authors is, when a `bar_toolchain` target is
-analyzed, what [configuration](/reference/glossary#configuration) does it see, and what transitions
-should be used for dependencies? The example above uses string attributes, but
-what would happen for a more complicated toolchain that depends on other targets
-in the Bazel repository?
-
-Let's see a more complex version of `bar_toolchain`:
-
-```python
-def _bar_toolchain_impl(ctx):
- # The implementation is mostly the same as above, so skipping.
- pass
-
-bar_toolchain = rule(
- implementation = _bar_toolchain_impl,
- attrs = {
- "compiler": attr.label(
- executable = True,
- mandatory = True,
- cfg = "exec",
- ),
- "system_lib": attr.label(
- mandatory = True,
- cfg = "target",
- ),
- "arch_flags": attr.string_list(),
- },
-)
-```
-
-The use of [`attr.label`](/rules/lib/toplevel/attr#label) is the same as for a standard rule,
-but the meaning of the `cfg` parameter is slightly different.
-
-The dependency from a target (called the "parent") to a toolchain via toolchain
-resolution uses a special configuration transition called the "toolchain
-transition". The toolchain transition keeps the configuration the same, except
-that it forces the execution platform to be the same for the toolchain as for
-the parent (otherwise, toolchain resolution for the toolchain could pick any
-execution platform, and wouldn't necessarily be the same as for parent). This
-allows any `exec` dependencies of the toolchain to also be executable for the
-parent's build actions. Any of the toolchain's dependencies which use `cfg =
-"target"` (or which don't specify `cfg`, since "target" is the default) are
-built for the same target platform as the parent. This allows toolchain rules to
-contribute both libraries (the `system_lib` attribute above) and tools (the
-`compiler` attribute) to the build rules which need them. The system libraries
-are linked into the final artifact, and so need to be built for the same
-platform, whereas the compiler is a tool invoked during the build, and needs to
-be able to run on the execution platform.
-
-## Registering and building with toolchains
-
-At this point all the building blocks are assembled, and you just need to make
-the toolchains available to Bazel's resolution procedure. This is done by
-registering the toolchain, either in a `MODULE.bazel` file using
-`register_toolchains()`, or by passing the toolchains' labels on the command
-line using the `--extra_toolchains` flag.
-
-```python
-register_toolchains(
- "//bar_tools:barc_linux_toolchain",
- "//bar_tools:barc_windows_toolchain",
- # Target patterns are also permitted, so you could have also written:
- # "//bar_tools:all",
- # or even
- # "//bar_tools/...",
-)
-```
-
-When using target patterns to register toolchains, the order in which the
-individual toolchains are registered is determined by the following rules:
-
-* The toolchains defined in a subpackage of a package are registered before the
- toolchains defined in the package itself.
-* Within a package, toolchains are registered in the lexicographical order of
- their names.
-
-Now when you build a target that depends on a toolchain type, an appropriate
-toolchain will be selected based on the target and execution platforms.
-
-```python
-# my_pkg/BUILD
-
-platform(
- name = "my_target_platform",
- constraint_values = [
- "@platforms//os:linux",
- ],
-)
-
-bar_binary(
- name = "my_bar_binary",
- ...
-)
-```
-
-```sh
-bazel build //my_pkg:my_bar_binary --platforms=//my_pkg:my_target_platform
-```
-
-Bazel will see that `//my_pkg:my_bar_binary` is being built with a platform that
-has `@platforms//os:linux` and therefore resolve the
-`//bar_tools:toolchain_type` reference to `//bar_tools:barc_linux_toolchain`.
-This will end up building `//bar_tools:barc_linux` but not
-`//bar_tools:barc_windows`.
-
-## Toolchain resolution
-
-Note: [Some Bazel rules](/concepts/platforms#status) do not yet support
-toolchain resolution.
-
-For each target that uses toolchains, Bazel's toolchain resolution procedure
-determines the target's concrete toolchain dependencies. The procedure takes as input a
-set of required toolchain types, the target platform, the list of available
-execution platforms, and the list of available toolchains. Its outputs are a
-selected toolchain for each toolchain type as well as a selected execution
-platform for the current target.
-
-The available execution platforms and toolchains are gathered from the
-external dependency graph via
-[`register_execution_platforms`](/rules/lib/globals/module#register_execution_platforms)
-and
-[`register_toolchains`](/rules/lib/globals/module#register_toolchains) calls in
-`MODULE.bazel`` files.
-Additional execution platforms and toolchains may also be specified on the
-command line via
-[`--extra_execution_platforms`](/reference/command-line-reference#flag--extra_execution_platforms)
-and
-[`--extra_toolchains`](/reference/command-line-reference#flag--extra_toolchains).
-The host platform is automatically included as an available execution platform.
-Available platforms and toolchains are tracked as ordered lists for determinism,
-with preference given to earlier items in the list.
-
-The set of available toolchains, in priority order, is created from
-`--extra_toolchains` and `register_toolchains`:
-
-1. Toolchains registered using `--extra_toolchains` are added first. (Within
- these, the **last** toolchain has highest priority.)
-2. Toolchains registered using `register_toolchains` in the transitive external
- dependency graph, in the following order: (Within these, the **first**
- mentioned toolchain has highest priority.)
- 1. Toolchains registered by the root module (as in, the `MODULE.bazel` at the
- workspace root);
- 2. Toolchains registered in the user's `WORKSPACE` file, including in any
- macros invoked from there;
- 3. Toolchains registered by non-root modules (as in, dependencies specified by
- the root module, and their dependencies, and so forth);
- 4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
- certain native rules bundled with the Bazel installation.
-
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/run/build#specifying-build-targets) are ordered by Bazel's package
-loading mechanism, which uses a lexicographic ordering.
-
-The resolution steps are as follows.
-
-1. A `target_compatible_with` or `exec_compatible_with` clause *matches* a
- platform if, for each `constraint_value` in its list, the platform also has
- that `constraint_value` (either explicitly or as a default).
-
- If the platform has `constraint_value`s from `constraint_setting`s not
- referenced by the clause, these do not affect matching.
-
-1. If the target being built specifies the
- [`exec_compatible_with` attribute](/reference/be/common-definitions#common.exec_compatible_with)
- (or its rule definition specifies the
- [`exec_compatible_with` argument](/rules/lib/globals/bzl#rule.exec_compatible_with)),
- the list of available execution platforms is filtered to remove
- any that do not match the execution constraints.
-
-1. For each available execution platform, you associate each toolchain type with
- the first available toolchain, if any, that is compatible with this execution
- platform and the target platform.
-
-1. Any execution platform that failed to find a compatible mandatory toolchain
- for one of its toolchain types is ruled out. Of the remaining platforms, the
- first one becomes the current target's execution platform, and its associated
- toolchains (if any) become dependencies of the target.
-
-The chosen execution platform is used to run all actions that the target
-generates.
-
-In cases where the same target can be built in multiple configurations (such as
-for different CPUs) within the same build, the resolution procedure is applied
-independently to each version of the target.
-
-If the rule uses [execution groups](/extending/exec-groups), each execution
-group performs toolchain resolution separately, and each has its own execution
-platform and toolchains.
-
-## Debugging toolchains
-
-If you are adding toolchain support to an existing rule, use the
-`--toolchain_resolution_debug=regex` flag. During toolchain resolution, the flag
-provides verbose output for toolchain types or target names that match the regex variable. You
-can use `.*` to output all information. Bazel will output names of toolchains it
-checks and skips during the resolution process.
-
-If you'd like to see which [`cquery`](/query/cquery) dependencies are from toolchain
-resolution, use `cquery`'s [`--transitions`](/query/cquery#transitions) flag:
-
-```
-# Find all direct dependencies of //cc:my_cc_lib. This includes explicitly
-# declared dependencies, implicit dependencies, and toolchain dependencies.
-$ bazel cquery 'deps(//cc:my_cc_lib, 1)'
-//cc:my_cc_lib (96d6638)
-@bazel_tools//tools/cpp:toolchain (96d6638)
-@bazel_tools//tools/def_parser:def_parser (HOST)
-//cc:my_cc_dep (96d6638)
-@local_config_platform//:host (96d6638)
-@bazel_tools//tools/cpp:toolchain_type (96d6638)
-//:default_host_platform (96d6638)
-@local_config_cc//:cc-compiler-k8 (HOST)
-//cc:my_cc_lib.cc (null)
-@bazel_tools//tools/cpp:grep-includes (HOST)
-
-# Which of these are from toolchain resolution?
-$ bazel cquery 'deps(//cc:my_cc_lib, 1)' --transitions=lite | grep "toolchain dependency"
- [toolchain dependency]#@local_config_cc//:cc-compiler-k8#HostTransition -> b6df211
-```
diff --git a/7.6.1/external/advanced.mdx b/7.6.1/external/advanced.mdx
deleted file mode 100644
index 26ece4d..0000000
--- a/7.6.1/external/advanced.mdx
+++ /dev/null
@@ -1,183 +0,0 @@
----
-title: 'Advanced topics on external dependencies'
----
-
-
-
-## Shadowing dependencies in WORKSPACE
-
-Note: This section applies to the [WORKSPACE
-system](/external/overview#workspace-system) only. For
-[Bzlmod](/external/overview#bzlmod), use a [multiple-version
-override](/external/module#multiple-version_override).
-
-Whenever possible, have a single version policy in your project, which is
-required for dependencies that you compile against and end up in your final
-binary. For other cases, you can shadow dependencies:
-
-myproject/WORKSPACE
-
-```python
-workspace(name = "myproject")
-
-local_repository(
- name = "A",
- path = "../A",
-)
-local_repository(
- name = "B",
- path = "../B",
-)
-```
-
-A/WORKSPACE
-
-```python
-workspace(name = "A")
-
-load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
-http_archive(
- name = "testrunner",
- urls = ["https://github.com/testrunner/v1.zip"],
- sha256 = "...",
-)
-```
-
-B/WORKSPACE {# This is not a buganizer link okay?? #}
-
-```python
-workspace(name = "B")
-
-load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
-http_archive(
- name = "testrunner",
- urls = ["https://github.com/testrunner/v2.zip"],
- sha256 = "..."
-)
-```
-
-Both dependencies `A` and `B` depend on different versions of `testrunner`.
-Include both in `myproject` without conflict by giving them distinct names in
-`myproject/WORKSPACE`:
-
-```python
-workspace(name = "myproject")
-
-load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
-http_archive(
- name = "testrunner-v1",
- urls = ["https://github.com/testrunner/v1.zip"],
- sha256 = "..."
-)
-http_archive(
- name = "testrunner-v2",
- urls = ["https://github.com/testrunner/v2.zip"],
- sha256 = "..."
-)
-local_repository(
- name = "A",
- path = "../A",
- repo_mapping = {"@testrunner" : "@testrunner-v1"}
-)
-local_repository(
- name = "B",
- path = "../B",
- repo_mapping = {"@testrunner" : "@testrunner-v2"}
-)
-```
-
-You can also use this mechanism to join diamonds. For example, if `A` and `B`
-have the same dependency but call it by different names, join those dependencies
-in `myproject/WORKSPACE`.
-
-## Overriding repositories from the command line
-
-To override a declared repository with a local repository from the command line,
-use the
-[`--override_repository`](/reference/command-line-reference#flag--override_repository)
-flag. Using this flag changes the contents of external repositories without
-changing your source code.
-
-For example, to override `@foo` to the local directory `/path/to/local/foo`,
-pass the `--override_repository=foo=/path/to/local/foo` flag.
-
-Use cases include:
-
-* Debugging issues. For example, to override an `http_archive` repository to a
- local directory where you can make changes more easily.
-* Vendoring. If you are in an environment where you cannot make network calls,
- override the network-based repository rules to point to local directories
- instead.
-
-Note: With [Bzlmod](/external/overview#bzlmod), remember to use canonical repo
-names here. Alternatively, use the
-[`--override_module`](/reference/command-line-reference#flag--override_module)
-flag to override a module to a local directory, similar to the
-[`local_path_override`](/rules/lib/globals/module#local_path_override) directive in
-`MODULE.bazel`.
-
-## Using proxies
-
-Bazel picks up proxy addresses from the `HTTPS_PROXY` and `HTTP_PROXY`
-environment variables and uses these to download `HTTP` and `HTTPS` files (if
-specified).
-
-## Support for IPv6
-
-On IPv6-only machines, Bazel can download dependencies with no changes. However,
-on dual-stack IPv4/IPv6 machines Bazel follows the same convention as Java,
-preferring IPv4 if enabled. In some situations, for example when the IPv4
-network cannot resolve/reach external addresses, this can cause `Network
-unreachable` exceptions and build failures. In these cases, you can override
-Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
-Specifically:
-
-* Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
- option](/docs/user-manual#startup-options), for example by adding the
- following line in your [`.bazelrc` file](/run/bazelrc):
-
- `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
-
-* When running Java build targets that need to connect to the internet (such
- as for integration tests), use the
- `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
- flag](/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
- file](/run/bazelrc):
-
- `build --jvmopt=-Djava.net.preferIPv6Addresses`
-
-* If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
- for dependency version resolution, also add
- `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
- variable to [provide JVM options for
- Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
-
-## Offline builds
-
-Sometimes you may wish to run a build offline, such as when traveling on an
-airplane. For such simple use cases, prefetch the needed repositories with
-`bazel fetch` or `bazel sync`. To disable fetching further repositories during
-the build, use the option `--nofetch`.
-
-For true offline builds, where a different entity supplies all needed files,
-Bazel supports the option `--distdir`. This flag tells Bazel to look first into
-the directories specified by that option when a repository rule asks Bazel to
-fetch a file with [`ctx.download`](/rules/lib/builtins/repository_ctx#download) or
-[`ctx.download_and_extract`](/rules/lib/builtins/repository_ctx#download_and_extract). By
-providing a hash sum of the file needed, Bazel looks for a file matching the
-basename of the first URL, and uses the local copy if the hash matches.
-
-Bazel itself uses this technique to bootstrap offline from the [distribution
-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)
-in an internal
-[`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
-
-Bazel allows execution of arbitrary commands in repository rules without knowing
-if they call out to the network, and so cannot enforce fully offline builds. To
-test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
diff --git a/7.6.1/external/lockfile.mdx b/7.6.1/external/lockfile.mdx
deleted file mode 100644
index f2a75b2..0000000
--- a/7.6.1/external/lockfile.mdx
+++ /dev/null
@@ -1,277 +0,0 @@
-keywords: product:Bazel,lockfile,Bzlmod
----
-title: 'Bazel Lockfile'
----
-
-
-
-The lockfile feature in Bazel enables the recording of specific versions or
-dependencies of software libraries or packages required by a project. It
-achieves this by storing the result of module resolution and extension
-evaluation. The lockfile promotes reproducible builds, ensuring consistent
-development environments. Additionally, it enhances build efficiency by allowing
-Bazel to skip the parts of the resolution process that are unaffected by changes
-in project dependencies. Furthermore, the lockfile improves stability by
-preventing unexpected updates or breaking changes in external libraries, thereby
-reducing the risk of introducing bugs.
-
-## Lockfile Generation
-
-The lockfile is generated under the workspace root with the name
-`MODULE.bazel.lock`. It is created or updated during the build process,
-specifically after module resolution and extension evaluation. Importantly, it
-only includes dependencies that are included in the current invocation of the
-build.
-
-When changes occur in the project that affect its dependencies, the lockfile is
-automatically updated to reflect the new state. This ensures that the lockfile
-remains focused on the specific set of dependencies required for the current
-build, providing an accurate representation of the project's resolved
-dependencies.
-
-## Lockfile Usage
-
-The lockfile can be controlled by the flag
-[`--lockfile_mode`](/reference/command-line-reference#flag--lockfile_mode) to
-customize the behavior of Bazel when the project state differs from the
-lockfile. The available modes are:
-
-* `update` (Default): Use the information that is present in the lockfile to
- skip downloads of known registry files and to avoid re-evaluating extensions
- whose results are still up-to-date. If information is missing, it will
- be added to the lockfile. In this mode, Bazel also avoids refreshing
- mutable information, such as yanked versions, for dependencies that haven't
- changed.
-* `refresh`: Like `update`, but mutable information is always refreshed when
- switching to this mode and roughly every hour while in this mode.
-* `error`: Like `update`, but if any information is missing or out-of-date,
- Bazel will fail with an error. This mode never changes the lockfile or
- performs network requests during resolution. Module extensions that marked
- themselves as `reproducible` may still perform network requests, but are
- expected to always produce the same result.
-* `off`: The lockfile is neither checked nor updated.
-
-## Lockfile Benefits
-
-The lockfile offers several benefits and can be utilized in various ways:
-
-- **Reproducible builds.** By capturing the specific versions or dependencies
- of software libraries, the lockfile ensures that builds are reproducible
- across different environments and over time. Developers can rely on
- consistent and predictable results when building their projects.
-
-- **Fast incremental resolutions.** The lockfile enables Bazel to avoid
- downloading registry files that were already used in a previous build.
- This significantly improves build efficiency, especially in scenarios where
- resolution can be time-consuming.
-
-- **Stability and risk reduction.** The lockfile helps maintain stability by
- preventing unexpected updates or breaking changes in external libraries. By
- locking the dependencies to specific versions, the risk of introducing bugs
- due to incompatible or untested updates is reduced.
-
-## Lockfile Contents
-
-The lockfile contains all the necessary information to determine whether the
-project state has changed. It also includes the result of building the project
-in the current state. The lockfile consists of two main parts:
-
-1. Hashes of all remote files that are inputs to module resolution.
-2. For each module extension, the lockfile includes inputs that affect it,
- represented by `bzlTransitiveDigest`, `usagesDigest` and other fields, as
- well as the output of running that extension, referred to as
- `generatedRepoSpecs`
-
-Here is an example that demonstrates the structure of the lockfile, along with
-explanations for each section:
-
-```json
-{
- "lockFileVersion": 10,
- "registryFileHashes": {
- "https://bcr.bazel.build/bazel_registry.json": "8a28e4af...5d5b3497",
- "https://bcr.bazel.build/modules/foo/1.0/MODULE.bazel": "7cd0312e...5c96ace2",
- "https://bcr.bazel.build/modules/foo/2.0/MODULE.bazel": "70390338... 9fc57589",
- "https://bcr.bazel.build/modules/foo/2.0/source.json": "7e3a9adf...170d94ad",
- "https://registry.mycorp.com/modules/foo/1.0/MODULE.bazel": "not found",
- ...
- },
- "selectedYankedVersions": {
- "foo@2.0": "Yanked for demo purposes"
- },
- "moduleExtensions": {
- "//:extension.bzl%lockfile_ext": {
- "general": {
- "bzlTransitiveDigest": "oWDzxG/aLnyY6Ubrfy....+Jp6maQvEPxn0pBM=",
- "usagesDigest": "aLmqbvowmHkkBPve05yyDNGN7oh7QE9kBADr3QIZTZs=",
- ...,
- "generatedRepoSpecs": {
- "hello": {
- "bzlFile": "@@//:extension.bzl",
- ...
- }
- }
- }
- },
- "//:extension.bzl%lockfile_ext2": {
- "os:macos": {
- "bzlTransitiveDigest": "oWDzxG/aLnyY6Ubrfy....+Jp6maQvEPxn0pBM=",
- "usagesDigest": "aLmqbvowmHkkBPve05y....yDNGN7oh7r3QIZTZs=",
- ...,
- "generatedRepoSpecs": {
- "hello": {
- "bzlFile": "@@//:extension.bzl",
- ...
- }
- }
- },
- "os:linux": {
- "bzlTransitiveDigest": "eWDzxG/aLsyY3Ubrto....+Jp4maQvEPxn0pLK=",
- "usagesDigest": "aLmqbvowmHkkBPve05y....yDNGN7oh7r3QIZTZs=",
- ...,
- "generatedRepoSpecs": {
- "hello": {
- "bzlFile": "@@//:extension.bzl",
- ...
- }
- }
- }
- }
- }
-}
-```
-
-### Registry File Hashes
-
-The `registryFileHashes` section contains the hashes of all files from
-remote registries accessed during module resolution. Since the resolution
-algorithm is fully deterministic when given the same inputs and all remote
-inputs are hashed, this ensures a fully reproducible resolution result while
-avoiding excessive duplication of remote information in the lockfile. Note that
-this also requires recording when a particular registry didn't contain a certain
-module, but a registry with lower precedence did (see the "not found" entry in
-the example). This inherently mutable information can be updated via
-`bazel mod deps --lockfile_mode=refresh`.
-
-Bazel uses the hashes from the lockfile to look up registry files in the
-repository cache before downloading them, which speeds up subsequent
-resolutions.
-
-### Selected Yanked Versions
-
-The `selectedYankedVersions` section contains the yanked versions of modules
-that were selected by module resolution. Since this usually result in an error
-when trying to build, this section is only non-empty when yanked versions are
-explicitly allowed via `--allow_yanked_versions` or
-`BZLMOD_ALLOW_YANKED_VERSIONS`.
-
-This field is needed since, compared to module files, yanked version information
-is inherently mutable and thus can't be referenced by a hash. This information
-can be updated via `bazel mod deps --lockfile_mode=refresh`.
-
-### Module Extensions
-
-The `moduleExtensions` section is a map that includes only the extensions used
-in the current invocation or previously invoked, while excluding any extensions
-that are no longer utilized. In other words, if an extension is not being used
-anymore across the dependency graph, it is removed from the `moduleExtensions`
-map.
-
-If an extension is independent of the operating system or architecture type,
-this section features only a single "general" entry. Otherwise, multiple
-entries are included, named after the OS, architecture, or both, with each
-corresponding to the result of evaluating the extension on those specifics.
-
-Each entry in the extension map corresponds to a used extension and is
-identified by its containing file and name. The corresponding value for each
-entry contains the relevant information associated with that extension:
-
-1. The `bzlTransitiveDigest` is the digest of the extension implementation
- and the .bzl files transitively loaded by it.
-2. The `usagesDigest` is the digest of the _usages_ of the extension in the
- dependency graph, which includes all tags.
-3. Further unspecified fields that track other inputs to the extension,
- such as contents of files or directories it reads or environment
- variables it uses.
-4. The `generatedRepoSpecs` encode the repositories created by the
- extension with the current input.
-5. The optional `moduleExtensionMetadata` field contains metadata provided by
- the extension such as whether certain repositories it created should be
- imported via `use_repo` by the root module. This information powers the
- `bazel mod tidy` command.
-
-Module extensions can opt out of being included in the lockfile by setting the
-returning metadata with `reproducible = True`. By doing so, they promise that
-they will always create the same repositories when given the same inputs.
-
-## Best Practices
-
-To maximize the benefits of the lockfile feature, consider the following best
-practices:
-
-* Regularly update the lockfile to reflect changes in project dependencies or
- configuration. This ensures that subsequent builds are based on the most
- up-to-date and accurate set of dependencies. To lock down all extensions
- at once, run `bazel mod deps --lockfile_mode=update`.
-
-* Include the lockfile in version control to facilitate collaboration and
- ensure that all team members have access to the same lockfile, promoting
- consistent development environments across the project.
-
-* Use [`bazelisk`](/install/bazelisk) to run Bazel, and include a
- `.bazelversion` file in version control that specifies the Bazel version
- corresponding to the lockfile. Because Bazel itself is a dependency of
- your build, the lockfile is specific to the Bazel version, and will
- change even between [backwards compatible](/release/backward-compatibility)
- Bazel releases. Using `bazelisk` ensures that all developers are using
- a Bazel version that matches the lockfile.
-
-By following these best practices, you can effectively utilize the lockfile
-feature in Bazel, leading to more efficient, reliable, and collaborative
-software development workflows.
-
-## Merge Conflicts
-
-The lockfile format is designed to minimize merge conflicts, but they can still
-happen.
-
-### Automatic Resolution
-
-Bazel provides a custom
-[git merge driver](https://git-scm.com/docs/gitattributes#_defining_a_custom_merge_driver)
-to help resolve these conflicts automatically.
-
-Set up the driver by adding this line to a `.gitattributes` file in the root of
-your git repository:
-
-```gitattributes
-# A custom merge driver for the Bazel lockfile.
-# https://bazel.build/external/lockfile#automatic-resolution
-MODULE.bazel.lock merge=bazel-lockfile-merge
-```
-
-Then each developer who wants to use the driver has to register it once by
-following these steps:
-
-1. Install [jq](https://jqlang.github.io/jq/download/) (1.5 or higher).
-2. Run the following commands:
-
-```bash
-jq_script=$(curl https://raw.githubusercontent.com/bazelbuild/bazel/master/scripts/bazel-lockfile-merge.jq)
-printf '%s\n' "${jq_script}" | less # to optionally inspect the jq script
-git config --global merge.bazel-lockfile-merge.name "Merge driver for the Bazel lockfile (MODULE.bazel.lock)"
-git config --global merge.bazel-lockfile-merge.driver "jq -s '${jq_script}' -- %O %A %B > %A.jq_tmp && mv %A.jq_tmp %A"
-```
-
-### Manual Resolution
-
-Simple merge conflicts in the `registryFileHashes` and `selectedYankedVersions`
-fields can be safely resolved by keeping all the entries from both sides of the
-conflict.
-
-Other types of merge conflicts should not be resolved manually. Instead:
-
-1. Restore the previous state of the lockfile
- via `git reset MODULE.bazel.lock && git checkout MODULE.bazel.lock`.
-2. Resolve any conflicts in the `MODULE.bazel` file.
-3. Run `bazel mod deps` to update the lockfile.
diff --git a/7.6.1/external/module.mdx b/7.6.1/external/module.mdx
deleted file mode 100644
index c5757fc..0000000
--- a/7.6.1/external/module.mdx
+++ /dev/null
@@ -1,223 +0,0 @@
----
-title: 'Bazel modules'
----
-
-
-
-A Bazel **module** is a Bazel project that can have multiple versions, each of
-which publishes metadata about other modules that it depends on. This is
-analogous to familiar concepts in other dependency management systems, such as a
-Maven *artifact*, an npm *package*, a Go *module*, or a Cargo *crate*.
-
-A module must have a `MODULE.bazel` file at its repo root. This file is the
-module's manifest, declaring its name, version, list of direct dependencies, and
-other information. For a basic example:
-
-```python
-module(name = "my-module", version = "1.0")
-
-bazel_dep(name = "rules_cc", version = "0.0.1")
-bazel_dep(name = "protobuf", version = "3.19.0")
-```
-
-See the [full list](/rules/lib/globals/module) of directives available in
-`MODULE.bazel` files.
-
-To perform module resolution, Bazel starts by reading the root module's
-`MODULE.bazel` file, and then repeatedly requests any dependency's
-`MODULE.bazel` file from a [Bazel registry](/external/registry) until it
-discovers the entire dependency graph.
-
-By default, Bazel then [selects](#version-selection) one version of each module
-to use. Bazel represents each module with a repo, and consults the registry
-again to learn how to define each of the repos.
-
-## Version format
-
-Bazel has a diverse ecosystem and projects use various versioning schemes. The
-most popular by far is [SemVer](https://semver.org), but there are
-also prominent projects using different schemes such as
-[Abseil](https://github.com/abseil/abseil-cpp/releases), whose
-versions are date-based, for example `20210324.2`).
-
-For this reason, Bzlmod adopts a more relaxed version of the SemVer spec. The
-differences include:
-
-* SemVer prescribes that the "release" part of the version must consist of 3
- segments: `MAJOR.MINOR.PATCH`. In Bazel, this requirement is loosened so
- that any number of segments is allowed.
-* In SemVer, each of the segments in the "release" part must be digits only.
- In Bazel, this is loosened to allow letters too, and the comparison
- semantics match the "identifiers" in the "prerelease" part.
-* Additionally, the semantics of major, minor, and patch version increases are
- not enforced. However, see [compatibility level](#compatibility_level) for
- details on how we denote backwards compatibility.
-
-Any valid SemVer version is a valid Bazel module version. Additionally, two
-SemVer versions `a` and `b` compare `a < b` if and only if the same holds when
-they're compared as Bazel module versions.
-
-## Version selection
-
-Consider the diamond dependency problem, a staple in the versioned dependency
-management space. Suppose you have the dependency graph:
-
-```
- A 1.0
- / \
- B 1.0 C 1.1
- | |
- D 1.0 D 1.1
-```
-
-Which version of `D` should be used? To resolve this question, Bzlmod uses the
-[Minimal Version Selection](https://research.swtch.com/vgo-mvs)
-(MVS) algorithm introduced in the Go module system. MVS assumes that all new
-versions of a module are backwards compatible, and so picks the highest version
-specified by any dependent (`D 1.1` in our example). It's called "minimal"
-because `D 1.1` is the earliest version that could satisfy our requirements —
-even if `D 1.2` or newer exists, we don't select them. Using MVS creates a
-version selection process that is *high-fidelity* and *reproducible*.
-
-### Yanked versions
-
-The registry can declare certain versions as *yanked* if they should be avoided
-(such as for security vulnerabilities). Bazel throws an error when selecting a
-yanked version of a module. To fix this error, either upgrade to a newer,
-non-yanked version, or use the
-[`--allow_yanked_versions`](/reference/command-line-reference#flag--allow_yanked_versions)
-flag to explicitly allow the yanked version.
-
-## Compatibility level
-
-In Go, MVS's assumption about backwards compatibility works because it treats
-backwards incompatible versions of a module as a separate module. In terms of
-SemVer, that means `A 1.x` and `A 2.x` are considered distinct modules, and can
-coexist in the resolved dependency graph. This is, in turn, made possible by
-encoding the major version in the package path in Go, so there aren't any
-compile-time or linking-time conflicts.
-
-Bazel, however, cannot provide such guarantees, so it needs the "major version"
-number in order to detect backwards incompatible versions. This number is called
-the *compatibility level*, and is specified by each module version in its
-`module()` directive. With this information, Bazel can throw an error when it
-detects that versions of the same module with different compatibility levels
-exist in the resolved dependency graph.
-
-## Overrides
-
-Specify overrides in the `MODULE.bazel` file to alter the behavior of Bazel
-module resolution. Only the root module's overrides take effect — if a module is
-used as a dependency, its overrides are ignored.
-
-Each override is specified for a certain module name, affecting all of its
-versions in the dependency graph. Although only the root module's overrides take
-effect, they can be for transitive dependencies that the root module does not
-directly depend on.
-
-### Single-version override
-
-The [`single_version_override`](/rules/lib/globals/module#single_version_override)
-serves multiple purposes:
-
-* With the `version` attribute, you can pin a dependency to a specific
- version, regardless of which versions of the dependency are requested in the
- dependency graph.
-* With the `registry` attribute, you can force this dependency to come from a
- specific registry, instead of following the normal [registry
- selection](/external/registry#selecting_registries) process.
-* With the `patch*` attributes, you can specify a set of patches to apply to
- the downloaded module.
-
-These attributes are all optional and can be mixed and matched with each other.
-
-### Multiple-version override
-
-A [`multiple_version_override`](/rules/lib/globals/module#multiple_version_override)
-can be specified to allow multiple versions of the same module to coexist in the
-resolved dependency graph.
-
-You can specify an explicit list of allowed versions for the module, which must
-all be present in the dependency graph before resolution — there must exist
-*some* transitive dependency depending on each allowed version. After
-resolution, only the allowed versions of the module remain, while Bazel upgrades
-other versions of the module to the nearest higher allowed version at the same
-compatibility level. If no higher allowed version at the same compatibility
-level exists, Bazel throws an error.
-
-For example, if versions `1.1`, `1.3`, `1.5`, `1.7`, and `2.0` exist in the
-dependency graph before resolution and the major version is the compatibility
-level:
-
-* A multiple-version override allowing `1.3`, `1.7`, and `2.0` results in
- `1.1` being upgraded to `1.3`, `1.5` being upgraded to `1.7`, and other
- versions remaining the same.
-* A multiple-version override allowing `1.5` and `2.0` results in an error, as
- `1.7` has no higher version at the same compatibility level to upgrade to.
-* A multiple-version override allowing `1.9` and `2.0` results in an error, as
- `1.9` is not present in the dependency graph before resolution.
-
-Additionally, users can also override the registry using the `registry`
-attribute, similarly to single-version overrides.
-
-### Non-registry overrides
-
-Non-registry overrides completely remove a module from version resolution. Bazel
-does not request these `MODULE.bazel` files from a registry, but instead from
-the repo itself.
-
-Bazel supports the following non-registry overrides:
-
-* [`archive_override`](/rules/lib/globals/module#archive_override)
-* [`git_override`](/rules/lib/globals/module#git_override)
-* [`local_path_override`](/rules/lib/globals/module#local_path_override)
-
-## Define repos that don't represent Bazel modules
-
-With `bazel_dep`, you can define repos that represent other Bazel modules.
-Sometimes there is a need to define a repo that does _not_ represent a Bazel
-module; for example, one that contains a plain JSON file to be read as data.
-
-In this case, you could use the [`use_repo_rule`
-directive](/rules/lib/globals/module#use_repo_rule) to directly define a repo
-by invoking a repo rule. This repo will only be visible to the module it's
-defined in.
-
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/external/extension), which lets you define repos with more
-flexibility.
-
-## Repository names and strict deps
-
-The [apparent name](/external/overview#apparent-repo-name) of a repo backing a
-module to its direct dependents defaults to its module name, unless the
-`repo_name` attribute of the [`bazel_dep`](/rules/lib/globals/module#bazel_dep)
-directive says otherwise. Note that this means a module can only find its direct
-dependencies. This helps prevent accidental breakages due to changes in
-transitive dependencies.
-
-The [canonical name](/external/overview#canonical-repo-name) of a repo backing a
-module is either `{{ "" }}module_name{{ "" }}~{{ "" }}version{{
-"" }}` (for example, `bazel_skylib~1.0.3`) or `{{ "" }}module_name{{
-"" }}~` (for example, `bazel_features~`), depending on whether there are
-multiple versions of the module in the entire dependency graph (see
-[`multiple_version_override`](/rules/lib/globals/module#multiple_version_override)).
-Note that **the canonical name format** is not an API you should depend on and
-**is subject to change at any time**. Instead of hard-coding the canonical name,
-use a supported way to get it directly from Bazel:
-
-* In BUILD and `.bzl` files, use
- [`Label.repo_name`](/rules/lib/builtins/Label#repo_name) on a `Label` instance
- constructed from a label string given by the apparent name of the repo, e.g.,
- `Label("@bazel_skylib").repo_name`.
-* When looking up runfiles, use
- [`$(rlocationpath ...)`](https://bazel.build/reference/be/make-variables#predefined_label_variables)
- or one of the runfiles libraries in
- `@bazel_tools//tools/{bash,cpp,java}/runfiles` or, for a ruleset `rules_foo`,
- in `@rules_foo//foo/runfiles`.
-* When interacting with Bazel from an external tool such as an IDE or language
- server, use the `bazel mod dump_repo_mapping` command to get the mapping from
- apparent names to canonical names for a given set of repositories.
-
-[Module extensions](/external/extension) can also introduce additional repos
-into the visible scope of a module.
diff --git a/7.6.1/help.mdx b/7.6.1/help.mdx
deleted file mode 100644
index a48d2b7..0000000
--- a/7.6.1/help.mdx
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: 'Getting Help'
----
-
-
-
-This page lists Bazel resources beyond the documentation and covers how to get
-support from the Bazel team and community.
-
-## Search existing material
-
-In addition to the documentation, you can find helpful information by searching:
-
-* [Bazel user group](https://groups.google.com/g/bazel-discuss)
-* [Bazel GitHub Discussions](https://github.com/bazelbuild/bazel/discussions)
-* [Bazel blog](https://blog.bazel.build/)
-* [Stack Overflow](https://stackoverflow.com/questions/tagged/bazel)
-* [`awesome-bazel` resources](https://github.com/jin/awesome-bazel)
-
-## Watch videos
-
-There are recordings of Bazel talks at various conferences, such as:
-
-* Bazel’s annual conference, BazelCon:
- * [BazelCon 2022](https://youtube.com/playlist?list=PLxNYxgaZ8RsdH4GCIZ69dzxQCOPyuNlpF)
- * [BazelCon 2021](https://www.youtube.com/playlist?list=PLxNYxgaZ8Rsc3auKhtfIB4qXAYf7whEux)
- * [BazelCon 2020](https://www.youtube.com/playlist?list=PLxNYxgaZ8RseRybXNbopHRv6-wGmFr04n)
- * [BazelCon 2019](https://youtu.be/eymphDN7No4?t=PLxNYxgaZ8Rsf-7g43Z8LyXct9ax6egdSj)
- * [BazelCon 2018](https://youtu.be/DVYRg6b2UBo?t=PLxNYxgaZ8Rsd3Nmvl1W1B4I6nK1674ezp)
- * [BazelCon 2017](https://youtu.be/3eFllvz8_0k?t=PLxNYxgaZ8RseY0KmkXQSt0StE71E7yizG)
-* Bazel day on [Google Open Source Live](https://opensourcelive.withgoogle.com/events/bazel)
-
-
-## Ask the Bazel community
-
-If there are no existing answers, you can ask the community by:
-
-* Emailing the [Bazel user group](https://groups.google.com/g/bazel-discuss)
-* Starting a discussion on [GitHub](https://github.com/bazelbuild/bazel/discussions)
-* Asking a question on [Stack Overflow](https://stackoverflow.com/questions/tagged/bazel)
-* Chatting with other Bazel contributors on [Slack](https://slack.bazel.build/)
-* Consulting a [Bazel community expert](/community/experts)
-
-## Understand Bazel's support level
-
-Please read the [release page](/release) to understand Bazel's release model and
-what level of support Bazel provides.
-
-## File a bug
-
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/7.6.1/install/bazelisk.mdx b/7.6.1/install/bazelisk.mdx
deleted file mode 100644
index a3189cb..0000000
--- a/7.6.1/install/bazelisk.mdx
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: 'Installing / Updating Bazel using Bazelisk'
----
-
-
-
-## Installing Bazel
-
-[Bazelisk](https://github.com/bazelbuild/bazelisk) is the
-recommended way to install Bazel on Ubuntu, Windows, and macOS. It automatically
-downloads and installs the appropriate version of Bazel. Use Bazelisk if you
-need to switch between different versions of Bazel depending on the current
-working directory, or to always keep Bazel updated to the latest release.
-
-For more details, see
-[the official README](https://github.com/bazelbuild/bazelisk/blob/master/README.md).
-
-## Updating Bazel
-
-Bazel has a [backward compatibility policy](/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/contribute/breaking-changes) if you
-are the author of one). That page summarizes best practices on how to test and
-migrate your project with upcoming incompatible changes and how to provide
-feedback to the incompatible change authors.
-
-### Managing Bazel versions with Bazelisk
-
-[Bazelisk](https://github.com/bazelbuild/bazelisk) helps you manage
-Bazel versions.
-
-Bazelisk can:
-
-* Auto-update Bazel to the latest LTS or rolling release.
-* Build the project with a Bazel version specified in the .bazelversion
- file. Check in that file into your version control to ensure reproducibility
- of your builds.
-* Help migrate your project for incompatible changes (see above)
-* Easily try release candidates
-
-### Recommended migration process
-
-Within minor updates to any LTS release, any
-project can be prepared for the next release without breaking
-compatibility with the current release. However, there may be
-backward-incompatible changes between major LTS versions.
-
-Follow this process to migrate from one major version to another:
-
-1. Read the release notes to get advice on how to migrate to the next version.
-1. Major incompatible changes should have an associated `--incompatible_*` flag
- and a corresponding GitHub issue:
- * Migration guidance is available in the associated GitHub issue.
- * Tooling is available for some of incompatible changes migration. For
- example, [buildifier](https://github.com/bazelbuild/buildtools/releases).
- * Report migration problems by commenting on the associated GitHub issue.
-
-After migration, you can continue to build your projects without worrying about
-backward-compatibility until the next major release.
diff --git a/7.6.1/install/compile-source.mdx b/7.6.1/install/compile-source.mdx
deleted file mode 100644
index 4b51f17..0000000
--- a/7.6.1/install/compile-source.mdx
+++ /dev/null
@@ -1,293 +0,0 @@
----
-title: 'Compiling Bazel from Source'
----
-
-
-
-This page describes how to install Bazel from source and provides
-troubleshooting tips for common issues.
-
-To build Bazel from source, you can do one of the following:
-
-* Build it [using an existing Bazel binary](#build-bazel-using-bazel)
-
-* Build it [without an existing Bazel binary](#bootstrap-bazel) which is known
- as _bootstrapping_.
-
-## Build Bazel using Bazel
-
-### Summary
-
-1. Get the latest Bazel release from the
- [GitHub release page](https://github.com/bazelbuild/bazel/releases) or with
- [Bazelisk](https://github.com/bazelbuild/bazelisk).
-
-2. [Download Bazel's sources from GitHub](https://github.com/bazelbuild/bazel/archive/master.zip)
- and extract somewhere.
- Alternatively you can git clone the source tree from https://github.com/bazelbuild/bazel
-
-3. Install the same prerequisites as for bootstrapping (see
- [for Unix-like systems](#bootstrap-unix-prereq) or
- [for Windows](#bootstrap-windows-prereq))
-
-4. Build a development build of Bazel using Bazel:
- `bazel build //src:bazel-dev` (or `bazel build //src:bazel-dev.exe` on
- Windows)
-
-5. The resulting binary is at `bazel-bin/src/bazel-dev`
- (or `bazel-bin\src\bazel-dev.exe` on Windows). You can copy it wherever you
- like and use immediately without further installation.
-
-Detailed instructions follow below.
-
-### Step 1: Get the latest Bazel release
-
-**Goal**: Install or download a release version of Bazel. Make sure you can run
-it by typing `bazel` in a terminal.
-
-**Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
-Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
-
-**Troubleshooting**:
-
-* If you cannot run Bazel by typing `bazel` in a terminal:
-
- * Maybe your Bazel binary's directory is not on the PATH.
-
- This is not a big problem. Instead of typing `bazel`, you will need to
- type the full path.
-
- * Maybe the Bazel binary itself is not called `bazel` (on Unixes) or
- `bazel.exe` (on Windows).
-
- This is not a big problem. You can either rename the binary, or type the
- binary's name instead of `bazel`.
-
- * Maybe the binary is not executable (on Unixes).
-
- You must make the binary executable by running `chmod +x /path/to/bazel`.
-
-### Step 2: Download Bazel's sources from GitHub
-
-If you are familiar with Git, then just git clone https://github.com/bazelbuild/bazel
-
-Otherwise:
-
-1. Download the
- [latest sources as a zip file](https://github.com/bazelbuild/bazel/archive/master.zip).
-
-2. Extract the contents somewhere.
-
- For example create a `bazel-src` directory under your home directory and
- extract there.
-
-### Step 3: Install prerequisites
-
-Install the same prerequisites as for bootstrapping (see below) -- JDK, C++
-compiler, MSYS2 (if you are building on Windows), etc.
-
-### Step 4a: Build Bazel on Ubuntu Linux, macOS, and other Unix-like systems
-
-For instructions for Windows, see [Build Bazel on Windows](#build-bazel-on-windows).
-
-**Goal**: Run Bazel to build a custom Bazel binary (`bazel-bin/src/bazel-dev`).
-
-**Instructions**:
-
-1. Start a Bash terminal
-
-2. `cd` into the directory where you extracted (or cloned) Bazel's sources.
-
- For example if you extracted the sources under your home directory, run:
-
- cd ~/bazel-src
-
-3. Build Bazel from source:
-
- bazel build //src:bazel-dev
-
- Alternatively you can run `bazel build //src:bazel --compilation_mode=opt`
- to yield a smaller binary but it's slower to build.
-
-4. The output will be at `bazel-bin/src/bazel-dev` (or `bazel-bin/src/bazel`).
-
-### Step 4b: Build Bazel on Windows
-
-For instructions for Unix-like systems, see
-[Ubuntu Linux, macOS, and other Unix-like systems](#build-bazel-on-unixes).
-
-**Goal**: Run Bazel to build a custom Bazel binary
-(`bazel-bin\src\bazel-dev.exe`).
-
-**Instructions**:
-
-1. Start Command Prompt (Start Menu > Run > "cmd.exe")
-
-2. `cd` into the directory where you extracted (or cloned) Bazel's sources.
-
- For example if you extracted the sources under your home directory, run:
-
- cd %USERPROFILE%\bazel-src
-
-3. Build Bazel from source:
-
- bazel build //src:bazel-dev.exe
-
- Alternatively you can run `bazel build //src:bazel.exe
- --compilation_mode=opt` to yield a smaller binary but it's slower to build.
-
-4. The output will be at `bazel-bin\src\bazel-dev.exe` (or
- `bazel-bin\src\bazel.exe`).
-
-### Step 5: Install the built binary
-
-Actually, there's nothing to install.
-
-The output of the previous step is a self-contained Bazel binary. You can copy
-it to any directory and use immediately. (It's useful if that directory is on
-your PATH so that you can run "bazel" everywhere.)
-
----
-
-## Build Bazel from scratch (bootstrapping)
-
-You can also build Bazel from scratch, without using an existing Bazel binary.
-
-### Step 1: Download Bazel's sources (distribution archive)
-
-(This step is the same for all platforms.)
-
-1. Download `bazel-Installing using Homebrew
- -### Step 1: Install Homebrew on macOS - -Install [Homebrew](https://brew.sh/) (a one-time step): - -```posix-terminal -/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" -``` - -### Step 2: Install Bazel via Homebrew - -Install the Bazel package via Homebrew as follows: - -```posix-terminal -brew install bazel -``` - -All set! You can confirm Bazel is installed successfully by running the -following command: - -```posix-terminal -bazel --version -``` - -Once installed, you can upgrade to a newer version of Bazel using the -following command: - -```posix-terminal -brew upgrade bazel -``` - -Installing using the binary installer
- -The binary installers are on Bazel's -[GitHub releases page](https://github.com/bazelbuild/bazel/releases). - -The installer contains the Bazel binary. Some additional libraries -must also be installed for Bazel to work. - -### Step 1: Install Xcode command line tools - -If you don't intend to use `ios_*` rules, it is sufficient to install the Xcode -command line tools package by using `xcode-select`: - -```posix-terminal -xcode-select --install -``` - -Otherwise, for `ios_*` rule support, you must have Xcode 6.1 or later with iOS -SDK 8.1 installed on your system. - -Download Xcode from the -[App Store](https://apps.apple.com/us/app/xcode/id497799835) or the -[Apple Developer site](https://developer.apple.com/download/more/?=xcode). - -Once Xcode is installed, accept the license agreement for all users with the -following command: - -```posix-terminal -sudo xcodebuild -license accept -``` - -### Step 2: Download the Bazel installer - -Next, download the Bazel binary installer named -`bazel-| Query | -Target Built | -Output | -
|---|---|---|
| bazel cquery "//x:tool" | -//x:tool | -//x:tool(targetconfig) | -
| bazel cquery "//x:tool" --universe_scope="//x:my_gen" | -//x:my_gen | -//x:tool(execconfig) | -
--bazelrc=file
-
- This flag is optional but can also be specified multiple times.
-
- `/dev/null` indicates that all further `--bazelrc`s will be ignored, which
- is useful to disable the search for a user rc file, such as in release
- builds.
-
- For example:
-
- ```
- --bazelrc=x.rc --bazelrc=y.rc --bazelrc=/dev/null --bazelrc=z.rc
- ```
-
- - `x.rc` and `y.rc` are read.
- - `z.rc` is ignored due to the prior `/dev/null`.
-
-In addition to this optional configuration file, Bazel looks for a global rc
-file. For more details, see the [global bazelrc section](#global-bazelrc).
-
-
-### `.bazelrc` syntax and semantics
-
-Like all UNIX "rc" files, the `.bazelrc` file is a text file with a line-based
-grammar. Empty lines and lines starting with `#` (comments) are ignored. Each
-line contains a sequence of words, which are tokenized according to the same
-rules as the Bourne shell.
-
-#### Imports
-
-Lines that start with `import` or `try-import` are special: use these to load
-other "rc" files. To specify a path that is relative to the workspace root,
-write `import %workspace%/path/to/bazelrc`.
-
-The difference between `import` and `try-import` is that Bazel fails if the
-`import`'ed file is missing (or can't be read), but not so for a `try-import`'ed
-file.
-
-Import precedence:
-
-- Options in the imported file take precedence over options specified before
- the import statement.
-- Options specified after the import statement take precedence over the
- options in the imported file.
-- Options in files imported later take precedence over files imported earlier.
-
-#### Option defaults
-
-Most lines of a bazelrc define default option values. The first word on each
-line specifies when these defaults are applied:
-
-- `startup`: startup options, which go before the command, and are described
- in `bazel help startup_options`.
-- `common`: options that should be applied to all Bazel commands that support
- them. If a command does not support an option specified in this way, the
- option is ignored so long as it is valid for *some* other Bazel command.
- Note that this only applies to option names: If the current command accepts
- an option with the specified name, but doesn't support the specified value,
- it will fail.
-- `always`: options that apply to all Bazel commands. If a command does not
- support an option specified in this way, it will fail.
-- _`command`_: Bazel command, such as `build` or `query` to which the options
- apply. These options also apply to all commands that inherit from the
- specified command. (For example, `test` inherits from `build`.)
-
-Each of these lines may be used more than once and the arguments that follow the
-first word are combined as if they had appeared on a single line. (Users of CVS,
-another tool with a "Swiss army knife" command-line interface, will find the
-syntax similar to that of `.cvsrc`.) For example, the lines:
-
-```posix-terminal
-build --test_tmpdir=/tmp/foo --verbose_failures
-
-build --test_tmpdir=/tmp/bar
-```
-
-are combined as:
-
-```posix-terminal
-build --test_tmpdir=/tmp/foo --verbose_failures --test_tmpdir=/tmp/bar
-```
-
-so the effective flags are `--verbose_failures` and `--test_tmpdir=/tmp/bar`.
-
-Option precedence:
-
-- Options on the command line always take precedence over those in rc files.
- For example, if a rc file says `build -c opt` but the command line flag is
- `-c dbg`, the command line flag takes precedence.
-- Within the rc file, precedence is governed by specificity: lines for a more
- specific command take precedence over lines for a less specific command.
-
- Specificity is defined by inheritance. Some commands inherit options from
- other commands, making the inheriting command more specific than the base
- command. For example `test` inherits from the `build` command, so all `bazel
- build` flags are valid for `bazel test`, and all `build` lines apply also to
- `bazel test` unless there's a `test` line for the same option. If the rc
- file says:
-
- ```posix-terminal
- test -c dbg --test_env=PATH
-
- build -c opt --verbose_failures
- ```
-
- then `bazel build //foo` will use `-c opt --verbose_failures`, and `bazel
- test //foo` will use `--verbose_failures -c dbg --test_env=PATH`.
-
- The inheritance (specificity) graph is:
-
- * Every command inherits from `common`
- * The following commands inherit from (and are more specific than)
- `build`: `test`, `run`, `clean`, `mobile-install`, `info`,
- `print_action`, `config`, `cquery`, and `aquery`
- * `coverage` inherits from `test`
-
-- Two lines specifying options for the same command at equal specificity are
- parsed in the order in which they appear within the file.
-
-- Because this precedence rule does not match the file order, it helps
- readability if you follow the precedence order within rc files: start with
- `common` options at the top, and end with the most-specific commands at the
- bottom of the file. This way, the order in which the options are read is the
- same as the order in which they are applied, which is more intuitive.
-
-The arguments specified on a line of an rc file may include arguments that are
-not options, such as the names of build targets, and so on. These, like the
-options specified in the same files, have lower precedence than their siblings
-on the command line, and are always prepended to the explicit list of non-
-option arguments.
-
-#### `--config`
-
-In addition to setting option defaults, the rc file can be used to group options
-and provide a shorthand for common groupings. This is done by adding a `:name`
-suffix to the command. These options are ignored by default, but will be
-included when the option --config=name is present,
-either on the command line or in a `.bazelrc` file, recursively, even inside of
-another config definition. The options specified by `command:name` will only be
-expanded for applicable commands, in the precedence order described above.
-
-Note: Configs can be defined in any `.bazelrc` file, and that all lines of
-the form `command:name` (for applicable commands) will be expanded, across the
-different rc files. In order to avoid name conflicts, we suggest that configs
-defined in personal rc files start with an underscore (`_`) to avoid
-unintentional name sharing.
-
-`--config=foo` expands to the options defined in
-[the rc files](#bazelrc-file-locations) "in-place" so that the options
-specified for the config have the same precedence that the `--config=foo` option
-had.
-
-This syntax does not extend to the use of `startup` to set
-[startup options](#option-defaults). Setting
-`startup:config-name --some_startup_option` in the .bazelrc will be ignored.
-
-#### Example
-
-Here's an example `~/.bazelrc` file:
-
-```
-# Bob's Bazel option defaults
-
-startup --host_jvm_args=-XX:-UseParallelGC
-import /home/bobs_project/bazelrc
-build --show_timestamps --keep_going --jobs 600
-build --color=yes
-query --keep_going
-
-# Definition of --config=memcheck
-build:memcheck --strip=never --test_timeout=3600
-```
-
-### Other files governing Bazel's behavior
-
-#### `.bazelignore`
-
-You can specify directories within the workspace
-that you want Bazel to ignore, such as related projects
-that use other build systems. Place a file called
-`.bazelignore` at the root of the workspace
-and add the directories you want Bazel to ignore, one per
-line. Entries are relative to the workspace root.
-
-### The global bazelrc file
-
-Bazel reads optional bazelrc files in this order:
-
-1. System rc-file located at `etc/bazel.bazelrc`.
-2. Workspace rc-file located at `$workspace/tools/bazel.rc`.
-3. Home rc-file located at `$HOME/.bazelrc`
-
-Each bazelrc file listed here has a corresponding flag which can be used to
-disable them (e.g. `--nosystem_rc`, `--noworkspace_rc`, `--nohome_rc`). You can
-also make Bazel ignore all bazelrcs by passing the `--ignore_all_rc_files`
-startup option.
diff --git a/7.6.1/run/client-server.mdx b/7.6.1/run/client-server.mdx
deleted file mode 100644
index 3819034..0000000
--- a/7.6.1/run/client-server.mdx
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: 'Client/server implementation'
----
-
-
-
-The Bazel system is implemented as a long-lived server process. This allows it
-to perform many optimizations not possible with a batch-oriented implementation,
-such as caching of BUILD files, dependency graphs, and other metadata from one
-build to the next. This improves the speed of incremental builds, and allows
-different commands, such as `build` and `query` to share the same cache of
-loaded packages, making queries very fast.
-
-When you run `bazel`, you're running the client. The client finds the server
-based on the output base, which by default is determined by the path of the base
-workspace directory and your userid, so if you build in multiple workspaces,
-you'll have multiple output bases and thus multiple Bazel server processes.
-Multiple users on the same workstation can build concurrently in the same
-workspace because their output bases will differ (different userids).
-
-If the client cannot find a running server instance, it starts a new one. It
-does this by checking if the output base already exists, implying the blaze
-archive has already been unpacked. Otherwise if the output base doesn't exist,
-the client unzips the archive's files and sets their `mtime`s to a date 9 years
-in the future. Once installed, the client confirms that the `mtime`s of the
-unzipped files are equal to the far off date to ensure no installation tampering
-has occurred.
-
-The server process will stop after a period of inactivity (3 hours, by default,
-which can be modified using the startup option `--max_idle_secs`). For the most
-part, the fact that there is a server running is invisible to the user, but
-sometimes it helps to bear this in mind. For example, if you're running scripts
-that perform a lot of automated builds in different directories, it's important
-to ensure that you don't accumulate a lot of idle servers; you can do this by
-explicitly shutting them down when you're finished with them, or by specifying
-a short timeout period.
-
-The name of a Bazel server process appears in the output of `ps x` or `ps -e f`
-as bazel(dirname), where _dirname_ is the basename of the
-directory enclosing the root of your workspace directory. For example:
-
-```posix-terminal
-ps -e f
-16143 ? Sl 3:00 bazel(src-johndoe2) -server -Djava.library.path=...
-```
-
-This makes it easier to find out which server process belongs to a given
-workspace. (Beware that with certain other options to `ps`, Bazel server
-processes may be named just `java`.) Bazel servers can be stopped using the
-[shutdown](/docs/user-manual#shutdown) command.
-
-When running `bazel`, the client first checks that the server is the appropriate
-version; if not, the server is stopped and a new one started. This ensures that
-the use of a long-running server process doesn't interfere with proper
-versioning.
diff --git a/7.6.1/run/scripts.mdx b/7.6.1/run/scripts.mdx
deleted file mode 100644
index 8f31490..0000000
--- a/7.6.1/run/scripts.mdx
+++ /dev/null
@@ -1,126 +0,0 @@
----
-title: 'Calling Bazel from scripts'
----
-
-
-
-You can call Bazel from scripts to perform a build, run tests, or query
-the dependency graph. Bazel has been designed to enable effective scripting, but
-this section lists some details to bear in mind to make your scripts more
-robust.
-
-### Choosing the output base
-
-The `--output_base` option controls where the Bazel process should write the
-outputs of a build to, as well as various working files used internally by
-Bazel, one of which is a lock that guards against concurrent mutation of the
-output base by multiple Bazel processes.
-
-Choosing the correct output base directory for your script depends on several
-factors. If you need to put the build outputs in a specific location, this will
-dictate the output base you need to use. If you are making a "read only" call to
-Bazel (such as `bazel query`), the locking factors will be more important. In
-particular, if you need to run multiple instances of your script concurrently,
-you will need to give each one a different (or random) output base.
-
-If you use the default output base value, you will be contending for the same
-lock used by the user's interactive Bazel commands. If the user issues
-long-running commands such as builds, your script will have to wait for those
-commands to complete before it can continue.
-
-### Notes about server mode
-
-By default, Bazel uses a long-running [server process](/run/client-server) as an
-optimization. When running Bazel in a script, don't forget to call `shutdown`
-when you're finished with the server, or, specify `--max_idle_secs=5` so that
-idle servers shut themselves down promptly.
-
-### What exit code will I get?
-
-Bazel attempts to differentiate failures due to the source code under
-consideration from external errors that prevent Bazel from executing properly.
-Bazel execution can result in following exit codes:
-
-**Exit Codes common to all commands:**
-
-- `0` - Success
-- `2` - Command Line Problem, Bad or Illegal flags or command combination, or
- Bad Environment Variables. Your command line must be modified.
-- `8` - Build Interrupted but we terminated with an orderly shutdown.
-- `9` - The server lock is held and `--noblock_for_lock` was passed.
-- `32` - External Environment Failure not on this machine.
-
-- `33` - Bazel ran out of memory and crashed. You need to modify your command line.
-- `34` - Reserved for Google-internal use.
-- `35` - Reserved for Google-internal use.
-- `36` - Local Environmental Issue, suspected permanent.
-- `37` - Unhandled Exception / Internal Bazel Error.
-- `38` - Reserved for Google-internal use.
-- `39` - Blobs required by Bazel are evicted from Remote Cache.
-- `41-44` - Reserved for Google-internal use.
-- `45` - Error publishing results to the Build Event Service.
-- `47` - Reserved for Google-internal use.
-
-**Return codes for commands `bazel build`, `bazel test`:**
-
-- `1` - Build failed.
-- `3` - Build OK, but some tests failed or timed out.
-- `4` - Build successful but no tests were found even though testing was
- requested.
-
-
-**For `bazel run`:**
-
-- `1` - Build failed.
-- If the build succeeds but the executed subprocess returns a non-zero exit
- code it will be the exit code of the command as well.
-
-**For `bazel query`:**
-
-- `3` - Partial success, but the query encountered 1 or more errors in the
- input BUILD file set and therefore the results of the operation are not 100%
- reliable. This is likely due to a `--keep_going` option on the command line.
-- `7` - Command failure.
-
-Future Bazel versions may add additional exit codes, replacing generic failure
-exit code `1` with a different non-zero value with a particular meaning.
-However, all non-zero exit values will always constitute an error.
-
-
-### Reading the .bazelrc file
-
-By default, Bazel reads the [`.bazelrc` file](/run/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
-.bazelrc file by using the option `--bazelrc=/dev/null`. If you want to perform
-a build using the user's preferred settings, the default behavior is better.
-
-### Command log
-
-The Bazel output is also available in a command log file which you can find with
-the following command:
-
-```posix-terminal
-bazel info command_log
-```
-
-The command log file contains the interleaved stdout and stderr streams of the
-most recent Bazel command. Note that running `bazel info` will overwrite the
-contents of this file, since it then becomes the most recent Bazel command.
-However, the location of the command log file will not change unless you change
-the setting of the `--output_base` or `--output_user_root` options.
-
-### Parsing output
-
-The Bazel output is quite easy to parse for many purposes. Two options that may
-be helpful for your script are `--noshow_progress` which suppresses progress
-messages, and --show_result n, which controls whether or
-not "build up-to-date" messages are printed; these messages may be parsed to
-discover which targets were successfully built, and the location of the output
-files they created. Be sure to specify a very large value of _n_ if you rely on
-these messages.
-
-## Troubleshooting performance by profiling
-
-See the [Performance Profiling](/rules/performance#performance-profiling) section.
diff --git a/7.6.1/start/android-app.mdx b/7.6.1/start/android-app.mdx
deleted file mode 100644
index 1a2a94f..0000000
--- a/7.6.1/start/android-app.mdx
+++ /dev/null
@@ -1,425 +0,0 @@
----
-title: 'Bazel Tutorial: Build an Android App'
----
-
-
-**Note:** There are known limitations on using Bazel for building Android apps.
-Visit the Github [team-Android hotlist](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Ateam-Android) to see the list of known issues. While the Bazel team and Open Source Software (OSS) contributors work actively to address known issues, users should be aware that Android Studio does not officially support Bazel projects.
-
-This tutorial covers how to build a simple Android app using Bazel.
-
-Bazel supports building Android apps using the
-[Android rules](/reference/be/android).
-
-This tutorial is intended for Windows, macOS and Linux users and does not
-require experience with Bazel or Android app development. You do not need to
-write any Android code in this tutorial.
-
-## What you'll learn
-
-In this tutorial you learn how to:
-
-* Set up your environment by installing Bazel and Android Studio, and
- downloading the sample project.
-* Set up a Bazel [workspace](/reference/be/workspace) that contains the source code
- for the app and a `WORKSPACE` file that identifies the top level of the
- workspace directory.
-* Update the `WORKSPACE` file to contain references to the required
- external dependencies, like the Android SDK.
-* Create a `BUILD` file.
-* Build the app with Bazel.
-* Deploy and run the app on an Android emulator or physical device.
-
-## Before you begin
-
-### Install Bazel
-
-Before you begin the tutorial, install the following software:
-
-* **Bazel.** To install, follow the [installation instructions](/install).
-* **Android Studio.** To install, follow the steps to [download Android
- Studio](https://developer.android.com/sdk/index.html).
- Execute the setup wizard to download the SDK and configure your environment.
-* (Optional) **Git.** Use `git` to download the Android app project.
-
-### Get the sample project
-
-For the sample project, use a basic Android app project in
-[Bazel's examples repository](https://github.com/bazelbuild/examples).
-
-This app has a single button that prints a greeting when clicked:
-
-
-
-**Figure 1.** Android app button greeting.
-
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
-
-```posix-terminal
-git clone https://github.com/bazelbuild/examples
-```
-
-The sample project for this tutorial is in `examples/android/tutorial`. For
-the rest of the tutorial, you will be executing commands in this directory.
-
-### Review the source files
-
-Take a look at the source files for the app.
-
-```
-.
-├── README.md
-└── src
- └── main
- ├── AndroidManifest.xml
- └── java
- └── com
- └── example
- └── bazel
- ├── AndroidManifest.xml
- ├── Greeter.java
- ├── MainActivity.java
- └── res
- ├── layout
- │ └── activity_main.xml
- └── values
- ├── colors.xml
- └── strings.xml
-```
-
-The key files and directories are:
-
-| Name | Location |
-| ----------------------- | ---------------------------------------------------------------------------------------- |
-| Android manifest files | `src/main/AndroidManifest.xml` and `src/main/java/com/example/bazel/AndroidManifest.xml` |
-| Android source files | `src/main/java/com/example/bazel/MainActivity.java` and `Greeter.java` |
-| Resource file directory | `src/main/java/com/example/bazel/res/` |
-
-
-## Build with Bazel
-
-### Set up the workspace
-
-A [workspace](/concepts/build-ref#workspace) is a directory that contains the
-source files for one or more software projects, and has a `WORKSPACE` file at
-its root.
-
-The `WORKSPACE` file may be empty or may contain references to [external
-dependencies](/docs/external) required to build your project.
-
-First, run the following command to create an empty `WORKSPACE` file:
-
-| OS | Command |
-| ------------------------ | ----------------------------------- |
-| Linux, macOS | `touch WORKSPACE` |
-| Windows (Command Prompt) | `type nul > WORKSPACE` |
-| Windows (PowerShell) | `New-Item WORKSPACE -ItemType file` |
-
-### Running Bazel
-
-You can now check if Bazel is running correctly with the command:
-
-```posix-terminal
-bazel info workspace
-```
-
-If Bazel prints the path of the current directory, you're good to go! If the
-`WORKSPACE` file does not exist, you may see an error message like:
-
-```
-ERROR: The 'info' command is only supported from within a workspace.
-```
-
-### Integrate with the Android SDK
-
-Bazel needs to run the Android SDK
-[build tools](https://developer.android.com/tools/revisions/build-tools.html)
-to build the app. This means that you need to add some information to your
-`WORKSPACE` file so that Bazel knows where to find them.
-
-Add the following line to your `WORKSPACE` file:
-
-```python
-android_sdk_repository(name = "androidsdk")
-```
-
-This will use the Android SDK at the path referenced by the `ANDROID_HOME`
-environment variable, and automatically detect the highest API level and the
-latest version of build tools installed within that location.
-
-You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
-Assuming the SDK is installed to default locations, you can use the following
-commands to set the `ANDROID_HOME` variable:
-
-| OS | Command |
-| ------------------------ | --------------------------------------------------- |
-| Linux | `export ANDROID_HOME=$HOME/Android/Sdk/` |
-| macOS | `export ANDROID_HOME=$HOME/Library/Android/sdk` |
-| Windows (Command Prompt) | `set ANDROID_HOME=%LOCALAPPDATA%\Android\Sdk` |
-| Windows (PowerShell) | `$env:ANDROID_HOME="$env:LOCALAPPDATA\Android\Sdk"` |
-
-The above commands set the variable only for the current shell session. To make
-them permanent, run the following commands:
-
-| OS | Command |
-| ------------------------ | --------------------------------------------------- |
-| Linux | `echo "export ANDROID_HOME=$HOME/Android/Sdk/" >> ~/.bashrc` |
-| macOS | `echo "export ANDROID_HOME=$HOME/Library/Android/Sdk/" >> ~/.bashrc` |
-| Windows (Command Prompt) | `setx ANDROID_HOME "%LOCALAPPDATA%\Android\Sdk"` |
-| Windows (PowerShell) | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
-
-You can also explicitly specify the absolute path of the Android SDK,
-the API level, and the version of build tools to use by including the `path`,
-`api_level`, and `build_tools_version` attributes. If `api_level` and
-`build_tools_version` are not specified, the `android_sdk_repository` rule will
-use the respective latest version available in the SDK. You can specify any
-combination of these attributes, as long as they are present in the SDK, for
-example:
-
-```python
-android_sdk_repository(
- name = "androidsdk",
- path = "/path/to/Android/sdk",
- api_level = 25,
- build_tools_version = "30.0.3"
-)
-```
-
-On Windows, note that the `path` attribute must use the mixed-style path, that
-is, a Windows path with forward slashes:
-
-```python
-android_sdk_repository(
- name = "androidsdk",
- path = "c:/path/to/Android/sdk",
-)
-```
-
-**Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
-and tell Bazel where to find it by adding the following line to your `WORKSPACE` file:
-
-```python
-android_ndk_repository(name = "androidndk")
-```
-
-Similar to `android_sdk_repository`, the path to the Android NDK is inferred
-from the `ANDROID_NDK_HOME` environment variable by default. The path can also
-be explicitly specified with a `path` attribute on `android_ndk_repository`.
-
-For more information, read [Using the Android Native Development Kit with
-Bazel](/docs/android-ndk).
-
-`api_level` is the version of the Android API that the SDK and NDK
-target - for example, 23 for Android 6.0 and 25 for Android 7.1. If not
-explicitly set, `api_level` defaults to the highest available API level for
-`android_sdk_repository` and `android_ndk_repository`.
-
-It's not necessary to set the API levels to the same value for the SDK and NDK.
-[This page](https://developer.android.com/ndk/guides/stable_apis.html)
-contains a map from Android releases to NDK-supported API levels.
-
-### Create a BUILD file
-
-A [`BUILD` file](/concepts/build-files) describes the relationship
-between a set of build outputs, like compiled Android resources from `aapt` or
-class files from `javac`, and their dependencies. These dependencies may be
-source files (Java, C++) in your workspace or other build outputs. `BUILD` files
-are written in a language called **Starlark**.
-
-`BUILD` files are part of a concept in Bazel known as the *package hierarchy*.
-The package hierarchy is a logical structure that overlays the directory
-structure in your workspace. Each [package](/concepts/build-ref#packages) is a
-directory (and its subdirectories) that contains a related set of source files
-and a `BUILD` file. The package also includes any subdirectories, excluding
-those that contain their own `BUILD` file. The *package name* is the path to the
-`BUILD` file relative to the `WORKSPACE`.
-
-Note that Bazel's package hierarchy is conceptually different from the Java
-package hierarchy of your Android App directory where the `BUILD` file is
-located, although the directories may be organized identically.
-
-For the simple Android app in this tutorial, the source files in `src/main/`
-comprise a single Bazel package. A more complex project may have many nested
-packages.
-
-#### Add an android_library rule
-
-A `BUILD` file contains several different types of declarations for Bazel. The
-most important type is the
-[build rule](/concepts/build-files#types-of-build-rules), which tells
-Bazel how to build an intermediate or final software output from a set of source
-files or other dependencies. Bazel provides two build rules,
-[`android_library`](/reference/be/android#android_library) and
-[`android_binary`](/reference/be/android#android_binary), that you can use to
-build an Android app.
-
-For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
-from the app source code and resource files. You'll then use the
-`android_binary` rule to tell Bazel how to build the Android application package.
-
-Create a new `BUILD` file in the `src/main/java/com/example/bazel` directory,
-and declare a new `android_library` target:
-
-`src/main/java/com/example/bazel/BUILD`:
-
-```python
-package(
- default_visibility = ["//src:__subpackages__"],
-)
-
-android_library(
- name = "greeter_activity",
- srcs = [
- "Greeter.java",
- "MainActivity.java",
- ],
- manifest = "AndroidManifest.xml",
- resource_files = glob(["res/**"]),
-)
-```
-
-The `android_library` build rule contains a set of attributes that specify the
-information that Bazel needs to build a library module from the source files.
-Note also that the name of the rule is `greeter_activity`. You'll reference the
-rule using this name as a dependency in the `android_binary` rule.
-
-#### Add an android_binary rule
-
-The [`android_binary`](/reference/be/android#android_binary) rule builds
-the Android application package (`.apk` file) for your app.
-
-Create a new `BUILD` file in the `src/main/` directory,
-and declare a new `android_binary` target:
-
-`src/main/BUILD`:
-
-```python
-android_binary(
- name = "app",
- manifest = "AndroidManifest.xml",
- deps = ["//src/main/java/com/example/bazel:greeter_activity"],
-)
-```
-
-Here, the `deps` attribute references the output of the `greeter_activity` rule
-you added to the `BUILD` file above. This means that when Bazel builds the
-output of this rule it checks first to see if the output of the
-`greeter_activity` library rule has been built and is up-to-date. If not, Bazel
-builds it and then uses that output to build the application package file.
-
-Now, save and close the file.
-
-### Build the app
-
-Try building the app! Run the following command to build the
-`android_binary` target:
-
-```posix-terminal
-bazel build //src/main:app
-```
-
-The [`build`](/docs/user-manual#build) subcommand instructs Bazel to build the
-target that follows. The target is specified as the name of a build rule inside
-a `BUILD` file, with along with the package path relative to your workspace
-directory. For this example, the target is `app` and the package path is
-`//src/main/`.
-
-Note that you can sometimes omit the package path or target name, depending on
-your current working directory at the command line and the name of the target.
-For more details about target labels and paths, see [Labels](/concepts/labels).
-
-Bazel will start to build the sample app. During the build process, its output
-will appear similar to the following:
-
-```bash
-INFO: Analysed target //src/main:app (0 packages loaded, 0 targets configured).
-INFO: Found 1 target...
-Target //src/main:app up-to-date:
- bazel-bin/src/main/app_deploy.jar
- bazel-bin/src/main/app_unsigned.apk
- bazel-bin/src/main/app.apk
-```
-
-#### Locate the build outputs
-
-Bazel puts the outputs of both intermediate and final build operations in a set
-of per-user, per-workspace output directories. These directories are symlinked
-from the following locations at the top-level of the project directory, where
-the `WORKSPACE` is:
-
-* `bazel-bin` stores binary executables and other runnable build outputs
-* `bazel-genfiles` stores intermediary source files that are generated by
- Bazel rules
-* `bazel-out` stores other types of build outputs
-
-Bazel stores the Android `.apk` file generated using the `android_binary` rule
-in the `bazel-bin/src/main` directory, where the subdirectory name `src/main` is
-derived from the name of the Bazel package.
-
-At a command prompt, list the contents of this directory and find the `app.apk`
-file:
-
-| OS | Command |
-| ------------------------ | ------------------------ |
-| Linux, macOS | `ls bazel-bin/src/main` |
-| Windows (Command Prompt) | `dir bazel-bin\src\main` |
-| Windows (PowerShell) | `ls bazel-bin\src\main` |
-
-
-### Run the app
-
-You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/docs/user-manual#mobile-install) command. This command uses
-the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
-can also choose to install the app on the Android emulator included in Android
-Studio. Make sure the emulator is running before executing the command below.
-
-Enter the following:
-
-```posix-terminal
-bazel mobile-install //src/main:app
-```
-
-Next, find and launch the "Bazel Tutorial App":
-
-
-
-**Figure 2.** Bazel tutorial app.
-
-**Congratulations! You have just installed your first Bazel-built Android app.**
-
-Note that the `mobile-install` subcommand also supports the
-[`--incremental`](/docs/user-manual#mobile-install) flag that can be used to
-deploy only those parts of the app that have changed since the last deployment.
-
-It also supports the `--start_app` flag to start the app immediately upon
-installing it.
-
-## Further reading
-
-For more details, see these pages:
-
-* Open issues on [GitHub](https://github.com/bazelbuild/bazel/issues)
-* More information on [mobile-install](/docs/mobile-install)
-* Integrate external dependencies like AppCompat, Guava and JUnit from Maven
- repositories using [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external)
-* Run Robolectric tests with the [robolectric-bazel](https://github.com/robolectric/robolectric-bazel)
- integration.
-* Testing your app with [Android instrumentation tests](/docs/android-instrumentation-test)
-* Integrating C and C++ code into your Android app with the [NDK](/docs/android-ndk)
-* See more Bazel example projects of:
- * [a Kotlin app](https://github.com/bazelbuild/rules_jvm_external/tree/master/examples/android_kotlin_app)
- * [Robolectric testing](https://github.com/bazelbuild/rules_jvm_external/tree/master/examples/android_local_test)
- * [Espresso testing](https://github.com/bazelbuild/rules_jvm_external/tree/master/examples/android_instrumentation_test)
-
-Happy building!
diff --git a/7.6.1/start/cpp.mdx b/7.6.1/start/cpp.mdx
deleted file mode 100644
index 70b3ba4..0000000
--- a/7.6.1/start/cpp.mdx
+++ /dev/null
@@ -1,405 +0,0 @@
----
-title: 'Bazel Tutorial: Build a C++ Project'
----
-
-
-
-## Introduction
-
-New to Bazel? You’re in the right place. Follow this First Build tutorial for a
-simplified introduction to using Bazel. This tutorial defines key terms as they
-are used in Bazel’s context and walks you through the basics of the Bazel
-workflow. Starting with the tools you need, you will build and run three
-projects with increasing complexity and learn how and why they get more complex.
-
-While Bazel is a [build system](https://bazel.build/basics/build-systems) that
-supports multi-language builds, this tutorial uses a C++ project as an example
-and provides the general guidelines and flow that apply to most languages.
-
-Estimated completion time: 30 minutes.
-
-### Prerequisites
-
-Start by [installing Bazel](https://bazel.build/install), if you haven’t
-already. This tutorial uses Git for source control, so for best results
-[install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as
-well.
-
-Next, retrieve the sample project from Bazel's GitHub repository by running the
-following in your command-line tool of choice:
-
-```posix-terminal
-git clone https://github.com/bazelbuild/examples
-```
-
-The sample project for this tutorial is in the `examples/cpp-tutorial` directory.
-
-Take a look below at how it’s structured:
-
-```
-examples
-└── cpp-tutorial
- ├──stage1
- │ ├── main
- │ │ ├── BUILD
- │ │ └── hello-world.cc
- │ └── WORKSPACE
- ├──stage2
- │ ├── main
- │ │ ├── BUILD
- │ │ ├── hello-world.cc
- │ │ ├── hello-greet.cc
- │ │ └── hello-greet.h
- │ └── WORKSPACE
- └──stage3
- ├── main
- │ ├── BUILD
- │ ├── hello-world.cc
- │ ├── hello-greet.cc
- │ └── hello-greet.h
- ├── lib
- │ ├── BUILD
- │ ├── hello-time.cc
- │ └── hello-time.h
- └── WORKSPACE
-```
-
-There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
-build both a binary and a library from a single package. In
-the third and final stage, you will build a project with multiple packages and
-build it with multiple targets.
-
-### Summary: Introduction
-
-By installing Bazel (and Git) and cloning the repository for this tutorial, you
-have laid the foundation for your first build with Bazel. Continue to the next
-section to define some terms and set up your [workspace](https://bazel.build/reference/glossary#workspace).
-
-## Getting started
-
-### Set up the workspace
-
- Before you can build a project, you need to set up its workspace. A workspace is
-a directory that holds your project's source files and Bazel's build outputs. It
-also contains these significant files:
-
-* The [`WORKSPACE` file](https://bazel.build/reference/glossary#workspace-file)
-, which identifies the directory and its contents as a Bazel workspace and
-lives at the root of the project's directory structure.
-* One or more [`BUILD` files](https://bazel.build/reference/glossary#build-file)
-, which tell Bazel how to build different parts of the project. A
-directory within the workspace that contains a BUILD file is a
-[package](https://bazel.build/reference/glossary#package). (More on packages
-later in this tutorial.)
-
-In future projects, to designate a directory as a Bazel workspace, create an
-empty file named `WORKSPACE` in that directory. For the purposes of this tutorial,
-a `WORKSPACE` file is already present in each stage.
-
-**NOTE**: When Bazel builds the project, all inputs must be in
-the same workspace. Files residing in different workspaces are independent of
-one another unless linked. More detailed information about workspace rules can
-be found in [this guide](https://bazel.build/reference/be/workspace).
-
-
-### Understand the BUILD file
-
-
-A `BUILD` file contains several different types of instructions for Bazel. Each
-`BUILD` file requires at least one [rule](https://bazel.build/reference/glossary#rule)
-as a set of instructions, which tells Bazel how to build the desired outputs,
-such as executable binaries or libraries. Each instance of a build rule in the
-`BUILD` file is called a [target](https://bazel.build/reference/glossary#target)
-and points to a specific set of source files and [dependencies](https://bazel.build/reference/glossary#dependency).
-A target can also point to other targets.
-
-Take a look at the `BUILD` file in the `cpp-tutorial/stage1/main` directory:
-
-```
-cc_binary(
- name = "hello-world",
- srcs = ["hello-world.cc"],
-)
-```
-
-In our example, the `hello-world` target instantiates Bazel's built-in
-[cc_binary rule](https://bazel.build/reference/be/c-cpp#cc_binary).
-The rule tells Bazel to build a self-contained executable binary from the
-hello-world.cc source file with no dependencies.
-
-### Summary: getting started
-
-Now you are familiar with some key terms, and what they mean in the context of
-this project and Bazel in general. In the next section, you will build and test
-Stage 1 of the project.
-
-
-## Stage 1: single target, single package
-
-It’s time to build the first part of the project. For a visual reference, the
-structure of the Stage 1 section of the project is:
-
-```
-examples
-└── cpp-tutorial
- └──stage1
- ├── main
- │ ├── BUILD
- │ └── hello-world.cc
- └── WORKSPACE
-```
-
-Run the following to move to the `cpp-tutorial/stage1` directory:
-
-```posix-terminal
-cd cpp-tutorial/stage1
-```
-
-Next, run:
-
-```posix-terminal
-bazel build //main:hello-world
-```
-
-In the target label, the `//main:` part is the location of the `BUILD` file
-relative to the root of the workspace, and `hello-world` is the target name in
-the `BUILD` file.
-
-Bazel produces something that looks like this:
-
-```
-INFO: Found 1 target...
-Target //main:hello-world up-to-date:
- bazel-bin/main/hello-world
-INFO: Elapsed time: 2.267s, Critical Path: 0.25s
-```
-
-You just built your first Bazel target. Bazel places build outputs in the
-`bazel-bin` directory at the root of the
-workspace.
-
-Now test your freshly built binary, which is:
-
-```posix-terminal
-bazel-bin/main/hello-world
-```
-
-This results in a printed “`Hello world`” message.
-
-Here’s the dependency graph of Stage 1:
-
-
-
-
-### Summary: stage 1
-
-Now that you have completed your first build, you have a basic idea of how a build
-is structured. In the next stage, you will add complexity by adding another
-target.
-
-## Stage 2: multiple build targets
-
-While a single target is sufficient for small projects, you may want to split
-larger projects into multiple targets and packages. This allows for fast
-incremental builds – that is, Bazel only rebuilds what's changed – and speeds up your
-builds by building multiple parts of a project at once. This stage of the
-tutorial adds a target, and the next adds a package.
-
-This is the directory you are working with for Stage 2:
-
-```
- ├──stage2
- │ ├── main
- │ │ ├── BUILD
- │ │ ├── hello-world.cc
- │ │ ├── hello-greet.cc
- │ │ └── hello-greet.h
- │ └── WORKSPACE
-```
-
-Take a look below at the `BUILD` file in the `cpp-tutorial/stage2/main` directory:
-
-```
-cc_library(
- name = "hello-greet",
- srcs = ["hello-greet.cc"],
- hdrs = ["hello-greet.h"],
-)
-
-cc_binary(
- name = "hello-world",
- srcs = ["hello-world.cc"],
- deps = [
- ":hello-greet",
- ],
-)
-```
-
-With this `BUILD` file, Bazel first builds the `hello-greet` library
-(using Bazel's built-in [cc_library rule](https://bazel.build/reference/be/c-cpp#cc_library)),
-then the hello-world binary. The deps attribute in
-the hello-world target tells Bazel that the hello-greet
-library is required to build the hello-world binary.
-
-Before you can build this new version of the project, you need to change
-directories, switching to the `cpp-tutorial/stage2` directory by running:
-
-```posix-terminal
-cd ../stage2
-```
-
-Now you can build the new binary using the following familiar command:
-
-```posix-terminal
-bazel build //main:hello-world
-```
-
-Once again, Bazel produces something that looks like this:
-
-```
-INFO: Found 1 target...
-Target //main:hello-world up-to-date:
- bazel-bin/main/hello-world
-INFO: Elapsed time: 2.399s, Critical Path: 0.30s
-```
-
-Now you can test your freshly built binary, which returns another “`Hello world`”:
-
-```posix-terminal
-bazel-bin/main/hello-world
-```
-
-If you now modify `hello-greet.cc` and rebuild the project, Bazel only recompiles
-that file.
-
-Looking at the dependency graph, you can see that `hello-world` depends on an extra input
-named `hello-greet`:
-
-
-
-### Summary: stage 2
-
-You've now built the project with two targets. The `hello-world` target builds
-one source file and depends on one other target (`//main:hello-greet`), which
-builds two additional source files. In the next section, take it a step further
-and add another package.
-
-## Stage 3: multiple packages
-
-This next stage adds another layer of complication and builds a project with
-multiple packages. Take a look below at the structure and contents of the
-`cpp-tutorial/stage3` directory:
-
-```
-└──stage3
- ├── main
- │ ├── BUILD
- │ ├── hello-world.cc
- │ ├── hello-greet.cc
- │ └── hello-greet.h
- ├── lib
- │ ├── BUILD
- │ ├── hello-time.cc
- │ └── hello-time.h
- └── WORKSPACE
-```
-
-You can see that now there are two sub-directories, and each contains a `BUILD`
-file. Therefore, to Bazel, the workspace now contains two packages: `lib` and
-`main`.
-
-Take a look at the `lib/BUILD` file:
-
-```
-cc_library(
- name = "hello-time",
- srcs = ["hello-time.cc"],
- hdrs = ["hello-time.h"],
- visibility = ["//main:__pkg__"],
-)
-```
-
-And at the `main/BUILD` file:
-
-```
-cc_library(
- name = "hello-greet",
- srcs = ["hello-greet.cc"],
- hdrs = ["hello-greet.h"],
-)
-
-cc_binary(
- name = "hello-world",
- srcs = ["hello-world.cc"],
- deps = [
- ":hello-greet",
- "//lib:hello-time",
- ],
-)
-```
-
-The `hello-world` target in the main package depends on the` hello-time` target
-in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
-this through the `deps` attribute. You can see this reflected in the dependency
-graph:
-
-
-
-For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
-explicitly visible to targets in `main/BUILD` using the visibility attribute.
-This is because by default targets are only visible to other targets in the same
-`BUILD` file. Bazel uses target visibility to prevent issues such as libraries
-containing implementation details leaking into public APIs.
-
-Now build this final version of the project. Switch to the `cpp-tutorial/stage3`
-directory by running:
-
-```posix-terminal
-cd ../stage3
-```
-
-Once again, run the following command:
-
-```posix-terminal
-bazel build //main:hello-world
-```
-
-Bazel produces something that looks like this:
-
-```
-INFO: Found 1 target...
-Target //main:hello-world up-to-date:
- bazel-bin/main/hello-world
-INFO: Elapsed time: 0.167s, Critical Path: 0.00s
-```
-
-Now test the last binary of this tutorial for a final `Hello world` message:
-
-```posix-terminal
-bazel-bin/main/hello-world
-```
-
-### Summary: stage 3
-
-You've now built the project as two packages with three targets and understand
-the dependencies between them, which equips you to go forth and build future
-projects with Bazel. In the next section, take a look at how to continue your
-Bazel journey.
-
-## Next steps
-
-You’ve now completed your first basic build with Bazel, but this is just the
-start. Here are some more resources to continue learning with Bazel:
-
-* To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/tutorials/cpp-use-cases).
-* To get started with building other applications with Bazel, see the tutorials
-for [Java](https://bazel.build/start/java), [Android application](https://bazel.build/start/android-app ),
-or [iOS application](https://bazel.build/start/ios-app)).
-* To learn more about working with local and remote repositories, read about
-[external dependencies](https://bazel.build/docs/external).
-* To learn more about Bazel’s other rules, see this [reference guide](https://bazel.build/rules).
-
-Happy building!
diff --git a/7.6.1/start/ios-app.mdx b/7.6.1/start/ios-app.mdx
deleted file mode 100644
index 0b860ab..0000000
--- a/7.6.1/start/ios-app.mdx
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: 'Bazel Tutorial: Build an iOS App'
----
-
-
-This tutorial has been moved into the [bazelbuild/rules_apple](https://github.com/bazelbuild/rules_apple/blob/master/doc/tutorials/ios-app.md) repository.
diff --git a/7.6.1/start/java.mdx b/7.6.1/start/java.mdx
deleted file mode 100644
index 7d7cbf6..0000000
--- a/7.6.1/start/java.mdx
+++ /dev/null
@@ -1,436 +0,0 @@
----
-title: 'Bazel Tutorial: Build a Java Project'
----
-
-
-
-This tutorial covers the basics of building Java applications with
-Bazel. You will set up your workspace and build a simple Java project that
-illustrates key Bazel concepts, such as targets and `BUILD` files.
-
-Estimated completion time: 30 minutes.
-
-## What you'll learn
-
-In this tutorial you learn how to:
-
-* Build a target
-* Visualize the project's dependencies
-* Split the project into multiple targets and packages
-* Control target visibility across packages
-* Reference targets through labels
-* Deploy a target
-
-## Before you begin
-
-### Install Bazel
-
-To prepare for the tutorial, first [Install Bazel](/install) if
-you don't have it installed already.
-
-### Install the JDK
-
-1. Install Java JDK (preferred version is 11, however versions between 8 and 15 are supported).
-
-2. Set the JAVA\_HOME environment variable to point to the JDK.
- * On Linux/macOS:
-
- export JAVA_HOME="$(dirname $(dirname $(realpath $(which javac))))"
- * On Windows:
- 1. Open Control Panel.
- 2. Go to "System and Security" > "System" > "Advanced System Settings" > "Advanced" tab > "Environment Variables..." .
- 3. Under the "User variables" list (the one on the top), click "New...".
- 4. In the "Variable name" field, enter `JAVA_HOME`.
- 5. Click "Browse Directory...".
- 6. Navigate to the JDK directory (for example `C:\Program Files\Java\jdk1.8.0_152`).
- 7. Click "OK" on all dialog windows.
-
-### Get the sample project
-
-Retrieve the sample project from Bazel's GitHub repository:
-
-```posix-terminal
-git clone https://github.com/bazelbuild/examples
-```
-
-The sample project for this tutorial is in the `examples/java-tutorial`
-directory and is structured as follows:
-
-```
-java-tutorial
-├── BUILD
-├── src
-│ └── main
-│ └── java
-│ └── com
-│ └── example
-│ ├── cmdline
-│ │ ├── BUILD
-│ │ └── Runner.java
-│ ├── Greeting.java
-│ └── ProjectRunner.java
-└── MODULE.bazel
-```
-
-## Build with Bazel
-
-### Set up the workspace
-
-Before you can build a project, you need to set up its workspace. A workspace is
-a directory that holds your project's source files and Bazel's build outputs. It
-also contains files that Bazel recognizes as special:
-
-* The `MODULE.bazel` file, which identifies the directory and its contents as a
- Bazel workspace and lives at the root of the project's directory structure,
-
-* One or more `BUILD` files, which tell Bazel how to build different parts of
- the project. (A directory within the workspace that contains a `BUILD` file
- is a *package*. You will learn about packages later in this tutorial.)
-
-To designate a directory as a Bazel workspace, create an empty file named
-`MODULE.bazel` in that directory.
-
-When Bazel builds the project, all inputs and dependencies must be in the same
-workspace. Files residing in different workspaces are independent of one
-another unless linked, which is beyond the scope of this tutorial.
-
-### Understand the BUILD file
-
-A `BUILD` file contains several different types of instructions for Bazel.
-The most important type is the *build rule*, which tells Bazel how to build the
-desired outputs, such as executable binaries or libraries. Each instance
-of a build rule in the `BUILD` file is called a *target* and points to a
-specific set of source files and dependencies. A target can also point to other
-targets.
-
-Take a look at the `java-tutorial/BUILD` file:
-
-```python
-java_binary(
- name = "ProjectRunner",
- srcs = glob(["src/main/java/com/example/*.java"]),
-)
-```
-
-In our example, the `ProjectRunner` target instantiates Bazel's built-in
-[`java_binary` rule](/reference/be/java#java_binary). The rule tells Bazel to
-build a `.jar` file and a wrapper shell script (both named after the target).
-
-The attributes in the target explicitly state its dependencies and options.
-While the `name` attribute is mandatory, many are optional. For example, in the
-`ProjectRunner` rule target, `name` is the name of the target, `srcs` specifies
-the source files that Bazel uses to build the target, and `main_class` specifies
-the class that contains the main method. (You may have noticed that our example
-uses [glob](/reference/be/functions#glob) to pass a set of source files to Bazel
-instead of listing them one by one.)
-
-### Build the project
-
-To build your sample project, navigate to the `java-tutorial` directory
-and run:
-
-```posix-terminal
-bazel build //:ProjectRunner
-```
-In the target label, the `//` part is the location of the `BUILD` file
-relative to the root of the workspace (in this case, the root itself),
-and `ProjectRunner` is the target name in the `BUILD` file. (You will
-learn about target labels in more detail at the end of this tutorial.)
-
-Bazel produces output similar to the following:
-
-```bash
- INFO: Found 1 target...
- Target //:ProjectRunner up-to-date:
- bazel-bin/ProjectRunner.jar
- bazel-bin/ProjectRunner
- INFO: Elapsed time: 1.021s, Critical Path: 0.83s
-```
-
-Congratulations, you just built your first Bazel target! Bazel places build
-outputs in the `bazel-bin` directory at the root of the workspace. Browse
-through its contents to get an idea for Bazel's output structure.
-
-Now test your freshly built binary:
-
-```posix-terminal
-bazel-bin/ProjectRunner
-```
-
-### Review the dependency graph
-
-Bazel requires build dependencies to be explicitly declared in BUILD files.
-Bazel uses those statements to create the project's dependency graph, which
-enables accurate incremental builds.
-
-To visualize the sample project's dependencies, you can generate a text
-representation of the dependency graph by running this command at the
-workspace root:
-
-```posix-terminal
-bazel query --notool_deps --noimplicit_deps "deps(//:ProjectRunner)" --output graph
-```
-
-The above command tells Bazel to look for all dependencies for the target
-`//:ProjectRunner` (excluding host and implicit dependencies) and format the
-output as a graph.
-
-Then, paste the text into [GraphViz](http://www.webgraphviz.com/).
-
-As you can see, the project has a single target that build two source files with
-no additional dependencies:
-
-
-
-After you set up your workspace, build your project, and examine its
-dependencies, then you can add some complexity.
-
-## Refine your Bazel build
-
-While a single target is sufficient for small projects, you may want to split
-larger projects into multiple targets and packages to allow for fast incremental
-builds (that is, only rebuild what's changed) and to speed up your builds by
-building multiple parts of a project at once.
-
-### Specify multiple build targets
-
-You can split the sample project build into two targets. Replace the contents of
-the `java-tutorial/BUILD` file with the following:
-
-```python
-java_binary(
- name = "ProjectRunner",
- srcs = ["src/main/java/com/example/ProjectRunner.java"],
- main_class = "com.example.ProjectRunner",
- deps = [":greeter"],
-)
-
-java_library(
- name = "greeter",
- srcs = ["src/main/java/com/example/Greeting.java"],
-)
-```
-
-With this configuration, Bazel first builds the `greeter` library, then the
-`ProjectRunner` binary. The `deps` attribute in `java_binary` tells Bazel that
-the `greeter` library is required to build the `ProjectRunner` binary.
-
-To build this new version of the project, run the following command:
-
-```posix-terminal
-bazel build //:ProjectRunner
-```
-
-Bazel produces output similar to the following:
-
-```
-INFO: Found 1 target...
-Target //:ProjectRunner up-to-date:
- bazel-bin/ProjectRunner.jar
- bazel-bin/ProjectRunner
-INFO: Elapsed time: 2.454s, Critical Path: 1.58s
-```
-
-Now test your freshly built binary:
-
-```posix-terminal
-bazel-bin/ProjectRunner
-```
-
-If you now modify `ProjectRunner.java` and rebuild the project, Bazel only
-recompiles that file.
-
-Looking at the dependency graph, you can see that `ProjectRunner` depends on the
-same inputs as it did before, but the structure of the build is different:
-
-
-
-You've now built the project with two targets. The `ProjectRunner` target builds
-two source files and depends on one other target (`:greeter`), which builds
-one additional source file.
-
-### Use multiple packages
-
-Let’s now split the project into multiple packages. If you take a look at the
-`src/main/java/com/example/cmdline` directory, you can see that it also contains
-a `BUILD` file, plus some source files. Therefore, to Bazel, the workspace now
-contains two packages, `//src/main/java/com/example/cmdline` and `//` (since
-there is a `BUILD` file at the root of the workspace).
-
-Take a look at the `src/main/java/com/example/cmdline/BUILD` file:
-
-```python
-java_binary(
- name = "runner",
- srcs = ["Runner.java"],
- main_class = "com.example.cmdline.Runner",
- deps = ["//:greeter"],
-)
-```
-
-The `runner` target depends on the `greeter` target in the `//` package (hence
-the target label `//:greeter`) - Bazel knows this through the `deps` attribute.
-Take a look at the dependency graph:
-
-
-
-However, for the build to succeed, you must explicitly give the `runner` target
-in `//src/main/java/com/example/cmdline/BUILD` visibility to targets in
-`//BUILD` using the `visibility` attribute. This is because by default targets
-are only visible to other targets in the same `BUILD` file. (Bazel uses target
-visibility to prevent issues such as libraries containing implementation details
-leaking into public APIs.)
-
-To do this, add the `visibility` attribute to the `greeter` target in
-`java-tutorial/BUILD` as shown below:
-
-```python
-java_library(
- name = "greeter",
- srcs = ["src/main/java/com/example/Greeting.java"],
- visibility = ["//src/main/java/com/example/cmdline:__pkg__"],
-)
-```
-
-Now you can build the new package by running the following command at the root
-of the workspace:
-
-```posix-terminal
-bazel build //src/main/java/com/example/cmdline:runner
-```
-
-Bazel produces output similar to the following:
-
-```
-INFO: Found 1 target...
-Target //src/main/java/com/example/cmdline:runner up-to-date:
- bazel-bin/src/main/java/com/example/cmdline/runner.jar
- bazel-bin/src/main/java/com/example/cmdline/runner
- INFO: Elapsed time: 1.576s, Critical Path: 0.81s
-```
-
-Now test your freshly built binary:
-
-```posix-terminal
-./bazel-bin/src/main/java/com/example/cmdline/runner
-```
-
-You've now modified the project to build as two packages, each containing one
-target, and understand the dependencies between them.
-
-
-## Use labels to reference targets
-
-In `BUILD` files and at the command line, Bazel uses target labels to reference
-targets - for example, `//:ProjectRunner` or
-`//src/main/java/com/example/cmdline:runner`. Their syntax is as follows:
-
-```
-//path/to/package:target-name
-```
-
-If the target is a rule target, then `path/to/package` is the path to the
-directory containing the `BUILD` file, and `target-name` is what you named the
-target in the `BUILD` file (the `name` attribute). If the target is a file
-target, then `path/to/package` is the path to the root of the package, and
-`target-name` is the name of the target file, including its full path.
-
-When referencing targets at the repository root, the package path is empty,
-just use `//:target-name`. When referencing targets within the same `BUILD`
-file, you can even skip the `//` workspace root identifier and just use
-`:target-name`.
-
-For example, for targets in the `java-tutorial/BUILD` file, you did not have to
-specify a package path, since the workspace root is itself a package (`//`), and
-your two target labels were simply `//:ProjectRunner` and `//:greeter`.
-
-However, for targets in the `//src/main/java/com/example/cmdline/BUILD` file you
-had to specify the full package path of `//src/main/java/com/example/cmdline`
-and your target label was `//src/main/java/com/example/cmdline:runner`.
-
-## Package a Java target for deployment
-
-Let’s now package a Java target for deployment by building the binary with all
-of its runtime dependencies. This lets you run the binary outside of your
-development environment.
-
-As you remember, the [java_binary](/reference/be/java#java_binary) build rule
-produces a `.jar` and a wrapper shell script. Take a look at the contents of
-`runner.jar` using this command:
-
-```posix-terminal
-jar tf bazel-bin/src/main/java/com/example/cmdline/runner.jar
-```
-
-The contents are:
-
-```
-META-INF/
-META-INF/MANIFEST.MF
-com/
-com/example/
-com/example/cmdline/
-com/example/cmdline/Runner.class
-```
-As you can see, `runner.jar` contains `Runner.class`, but not its dependency,
-`Greeting.class`. The `runner` script that Bazel generates adds `greeter.jar`
-to the classpath, so if you leave it like this, it will run locally, but it
-won't run standalone on another machine. Fortunately, the `java_binary` rule
-allows you to build a self-contained, deployable binary. To build it, append
-`_deploy.jar` to the target name:
-
-```posix-terminal
-bazel build //src/main/java/com/example/cmdline:runner_deploy.jar
-```
-
-Bazel produces output similar to the following:
-
-```
-INFO: Found 1 target...
-Target //src/main/java/com/example/cmdline:runner_deploy.jar up-to-date:
- bazel-bin/src/main/java/com/example/cmdline/runner_deploy.jar
-INFO: Elapsed time: 1.700s, Critical Path: 0.23s
-```
-You have just built `runner_deploy.jar`, which you can run standalone away from
-your development environment since it contains the required runtime
-dependencies. Take a look at the contents of this standalone JAR using the
-same command as before:
-
-```posix-terminal
-jar tf bazel-bin/src/main/java/com/example/cmdline/runner_deploy.jar
-```
-
-The contents include all of the necessary classes to run:
-
-```
-META-INF/
-META-INF/MANIFEST.MF
-build-data.properties
-com/
-com/example/
-com/example/cmdline/
-com/example/cmdline/Runner.class
-com/example/Greeting.class
-```
-
-## Further reading
-
-For more details, see:
-
-* [rules_jvm_external](https://github.com/bazelbuild/rules_jvm_external) for
- rules to manage transitive Maven dependencies.
-
-* [External Dependencies](/docs/external) to learn more about working with
- local and remote repositories.
-
-* The [other rules](/rules) to learn more about Bazel.
-
-* The [C++ build tutorial](/start/cpp) to get started with building
- C++ projects with Bazel.
-
-* The [Android application tutorial](/start/android-app ) and
- [iOS application tutorial](/start/ios-app)) to get started with
- building mobile applications for Android and iOS with Bazel.
-
-Happy building!
diff --git a/7.6.1/tutorials/cpp-dependency.mdx b/7.6.1/tutorials/cpp-dependency.mdx
deleted file mode 100644
index 194cc73..0000000
--- a/7.6.1/tutorials/cpp-dependency.mdx
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: 'Review the dependency graph'
----
-
-
-
-A successful build has all of its dependencies explicitly stated in the `BUILD`
-file. Bazel uses those statements to create the project's dependency graph,
-which enables accurate incremental builds.
-
-To visualize the sample project's dependencies, you can generate a text
-representation of the dependency graph by running this command at the
-workspace root:
-
-```
-bazel query --notool_deps --noimplicit_deps "deps(//main:hello-world)" \
- --output graph
-```
-
-The above command tells Bazel to look for all dependencies for the target
-`//main:hello-world` (excluding host and implicit dependencies) and format the
-output as a graph.
-
-Then, paste the text into [GraphViz](http://www.webgraphviz.com/).
-
-On Ubuntu, you can view the graph locally by installing GraphViz and the xdot
-Dot Viewer:
-
-```
-sudo apt update && sudo apt install graphviz xdot
-```
-
-Then you can generate and view the graph by piping the text output above
-straight to xdot:
-
-```
-xdot <(bazel query --notool_deps --noimplicit_deps "deps(//main:hello-world)" \
- --output graph)
-```
-
-As you can see, the first stage of the sample project has a single target
-that builds a single source file with no additional dependencies:
-
-
-
-**Figure 1.** Dependency graph for `hello-world` displays a single target with a single
-source file.
-
-After you set up your workspace, build your project, and examine its
-dependencies, then you can add some complexity.
diff --git a/7.6.1/tutorials/cpp-labels.mdx b/7.6.1/tutorials/cpp-labels.mdx
deleted file mode 100644
index b0fc953..0000000
--- a/7.6.1/tutorials/cpp-labels.mdx
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: 'Use labels to reference targets'
----
-
-
-
-In `BUILD` files and at the command line, Bazel uses *labels* to reference
-targets - for example, `//main:hello-world` or `//lib:hello-time`. Their syntax
-is:
-
-```
-//path/to/package:target-name
-```
-
-If the target is a rule target, then `path/to/package` is the path from the
-workspace root (the directory containing the `WORKSPACE` file) to the directory
-containing the `BUILD` file, and `target-name` is what you named the target
-in the `BUILD` file (the `name` attribute). If the target is a file target,
-then `path/to/package` is the path to the root of the package, and
-`target-name` is the name of the target file, including its full
-path relative to the root of the package (the directory containing the
-package's `BUILD` file).
-
-When referencing targets at the repository root, the package path is empty,
-just use `//:target-name`. When referencing targets within the same `BUILD`
-file, you can even skip the `//` workspace root identifier and just use
-`:target-name`.
diff --git a/7.6.1/tutorials/cpp-use-cases.mdx b/7.6.1/tutorials/cpp-use-cases.mdx
deleted file mode 100644
index 4bcfaf3..0000000
--- a/7.6.1/tutorials/cpp-use-cases.mdx
+++ /dev/null
@@ -1,259 +0,0 @@
----
-title: 'Common C++ Build Use Cases'
----
-
-
-
-Here you will find some of the most common use cases for building C++ projects
-with Bazel. If you have not done so already, get started with building C++
-projects with Bazel by completing the tutorial
-[Introduction to Bazel: Build a C++ Project](/start/cpp).
-
-For information on cc_library and hdrs header files, see
-cc_library.
-
-## Including multiple files in a target
-
-You can include multiple files in a single target with
-glob.
-For example:
-
-```python
-cc_library(
- name = "build-all-the-files",
- srcs = glob(["*.cc"]),
- hdrs = glob(["*.h"]),
-)
-```
-
-With this target, Bazel will build all the `.cc` and `.h` files it finds in the
-same directory as the `BUILD` file that contains this target (excluding
-subdirectories).
-
-## Using transitive includes
-
-If a file includes a header, then any rule with that file as a source (that is,
-having that file in the `srcs`, `hdrs`, or `textual_hdrs` attribute) should
-depend on the included header's library rule. Conversely, only direct
-dependencies need to be specified as dependencies. For example, suppose
-`sandwich.h` includes `bread.h` and `bread.h` includes `flour.h`. `sandwich.h`
-doesn't include `flour.h` (who wants flour in their sandwich?), so the `BUILD`
-file would look like this:
-
-```python
-cc_library(
- name = "sandwich",
- srcs = ["sandwich.cc"],
- hdrs = ["sandwich.h"],
- deps = [":bread"],
-)
-
-cc_library(
- name = "bread",
- srcs = ["bread.cc"],
- hdrs = ["bread.h"],
- deps = [":flour"],
-)
-
-cc_library(
- name = "flour",
- srcs = ["flour.cc"],
- hdrs = ["flour.h"],
-)
-```
-
-Here, the `sandwich` library depends on the `bread` library, which depends
-on the `flour` library.
-
-## Adding include paths
-
-Sometimes you cannot (or do not want to) root include paths at the workspace
-root. Existing libraries might already have an include directory that doesn't
-match its path in your workspace. For example, suppose you have the following
-directory structure:
-
-```
-└── my-project
- ├── legacy
- │ └── some_lib
- │ ├── BUILD
- │ ├── include
- │ │ └── some_lib.h
- │ └── some_lib.cc
- └── WORKSPACE
-```
-
-Bazel will expect `some_lib.h` to be included as
-`legacy/some_lib/include/some_lib.h`, but suppose `some_lib.cc` includes
-`"some_lib.h"`. To make that include path valid,
-`legacy/some_lib/BUILD` will need to specify that the `some_lib/include`
-directory is an include directory:
-
-```python
-cc_library(
- name = "some_lib",
- srcs = ["some_lib.cc"],
- hdrs = ["include/some_lib.h"],
- copts = ["-Ilegacy/some_lib/include"],
-)
-```
-
-This is especially useful for external dependencies, as their header files
-must otherwise be included with a `/` prefix.
-
-## Including external libraries
-
-Suppose you are using [Google Test](https://github.com/google/googletest).
-You can use one of the repository functions in the `WORKSPACE` file to
-download Google Test and make it available in your repository:
-
-```python
-load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
-
-http_archive(
- name = "gtest",
- url = "https://github.com/google/googletest/archive/release-1.10.0.zip",
- sha256 = "94c634d499558a76fa649edb13721dce6e98fb1e7018dfaeba3cd7a083945e91",
- build_file = "@//:gtest.BUILD",
-)
-```
-
-Note: If the destination already contains a `BUILD` file, you can leave
-out the `build_file` attribute.
-
-Then create `gtest.BUILD`, a `BUILD` file used to compile Google Test.
-Google Test has several "special" requirements that make its `cc_library` rule
-more complicated:
-
-* `googletest-release-1.10.0/src/gtest-all.cc` `#include`s all other
- files in `googletest-release-1.10.0/src/`: exclude it from the
- compile to prevent link errors for duplicate symbols.
-
-* It uses header files that are relative to the
-`googletest-release-1.10.0/include/` directory (`"gtest/gtest.h"`), so you must
-add that directory to the include paths.
-
-* It needs to link in `pthread`, so add that as a `linkopt`.
-
-The final rule therefore looks like this:
-
-```python
-cc_library(
- name = "main",
- srcs = glob(
- ["googletest-release-1.10.0/src/*.cc"],
- exclude = ["googletest-release-1.10.0/src/gtest-all.cc"]
- ),
- hdrs = glob([
- "googletest-release-1.10.0/include/**/*.h",
- "googletest-release-1.10.0/src/*.h"
- ]),
- copts = [
- "-Iexternal/gtest/googletest-release-1.10.0/include",
- "-Iexternal/gtest/googletest-release-1.10.0"
- ],
- linkopts = ["-pthread"],
- visibility = ["//visibility:public"],
-)
-```
-
-This is somewhat messy: everything is prefixed with `googletest-release-1.10.0`
-as a byproduct of the archive's structure. You can make `http_archive` strip
-this prefix by adding the `strip_prefix` attribute:
-
-```python
-load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
-
-http_archive(
- name = "gtest",
- url = "https://github.com/google/googletest/archive/release-1.10.0.zip",
- sha256 = "94c634d499558a76fa649edb13721dce6e98fb1e7018dfaeba3cd7a083945e91",
- build_file = "@//:gtest.BUILD",
- strip_prefix = "googletest-release-1.10.0",
-)
-```
-
-Then `gtest.BUILD` would look like this:
-
-```python
-cc_library(
- name = "main",
- srcs = glob(
- ["src/*.cc"],
- exclude = ["src/gtest-all.cc"]
- ),
- hdrs = glob([
- "include/**/*.h",
- "src/*.h"
- ]),
- copts = ["-Iexternal/gtest/include"],
- linkopts = ["-pthread"],
- visibility = ["//visibility:public"],
-)
-```
-
-Now `cc_` rules can depend on `@gtest//:main`.
-
-## Writing and running C++ tests
-
-For example, you could create a test `./test/hello-test.cc`, such as:
-
-```cpp
-#include "gtest/gtest.h"
-#include "main/hello-greet.h"
-
-TEST(HelloTest, GetGreet) {
- EXPECT_EQ(get_greet("Bazel"), "Hello Bazel");
-}
-```
-
-Then create `./test/BUILD` file for your tests:
-
-```python
-cc_test(
- name = "hello-test",
- srcs = ["hello-test.cc"],
- copts = ["-Iexternal/gtest/include"],
- deps = [
- "@gtest//:main",
- "//main:hello-greet",
- ],
-)
-```
-
-To make `hello-greet` visible to `hello-test`, you must add
-`"//test:__pkg__",` to the `visibility` attribute in `./main/BUILD`.
-
-Now you can use `bazel test` to run the test.
-
-```
-bazel test test:hello-test
-```
-
-This produces the following output:
-
-```
-INFO: Found 1 test target...
-Target //test:hello-test up-to-date:
- bazel-bin/test/hello-test
-INFO: Elapsed time: 4.497s, Critical Path: 2.53s
-//test:hello-test PASSED in 0.3s
-
-Executed 1 out of 1 tests: 1 test passes.
-```
-
-
-## Adding dependencies on precompiled libraries
-
-If you want to use a library of which you only have a compiled version (for
-example, headers and a `.so` file) wrap it in a `cc_library` rule:
-
-```python
-cc_library(
- name = "mylib",
- srcs = ["mylib.so"],
- hdrs = ["mylib.h"],
-)
-```
-
-This way, other C++ targets in your workspace can depend on this rule.
diff --git a/7.6.1/versions/index.mdx b/7.6.1/versions/index.mdx
deleted file mode 100644
index c92a15b..0000000
--- a/7.6.1/versions/index.mdx
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: 'Documentation Versions'
----
-
-
-
-The documentation on this website represents the latest in Bazel. Documentation
-is updated at head. Each major supported release will have a snapshot of the
-narrative and reference documentation that follows the lifecycle of Bazel's
-version support.
-
-For now, to see documentation for older Bazel versions, go to
-[docs.bazel.build](https://docs.bazel.build/).
-
-
- To the Archives!
-
diff --git a/8.0.1/about/faq.mdx b/8.0.1/about/faq.mdx
deleted file mode 100644
index dd5be8a..0000000
--- a/8.0.1/about/faq.mdx
+++ /dev/null
@@ -1,209 +0,0 @@
----
-title: 'FAQ'
----
-
-
-
-If you have questions or need support, see [Getting Help](/help).
-
-## What is Bazel?
-
-Bazel is a tool that automates software builds and tests. Supported build tasks include running compilers and linkers to produce executable programs and libraries, and assembling deployable packages for Android, iOS and other target environments. Bazel is similar to other tools like Make, Ant, Gradle, Buck, Pants and Maven.
-
-## What is special about Bazel?
-
-Bazel was designed to fit the way software is developed at Google. It has the following features:
-
-* Multi-language support: Bazel supports [many languages](/reference/be/overview), and can be extended to support arbitrary programming languages.
-* High-level build language: Projects are described in the `BUILD` language, a concise text format that describes a project as sets of small interconnected libraries, binaries and tests. In contrast, with tools like Make, you have to describe individual files and compiler invocations.
-* Multi-platform support: The same tool and the same `BUILD` files can be used to build software for different architectures, and even different platforms. At Google, we use Bazel to build everything from server applications running on systems in our data centers to client apps running on mobile phones.
-* Reproducibility: In `BUILD` files, each library, test and binary must specify its direct dependencies completely. Bazel uses this dependency information to know what must be rebuilt when you make changes to a source file, and which tasks can run in parallel. This means that all builds are incremental and will always produce the same result.
-* Scalable: Bazel can handle large builds; at Google, it is common for a server binary to have 100k source files, and builds where no files were changed take about ~200ms.
-
-## Why doesn’t Google use...?
-
-* Make, Ninja: These tools give very exact control over what commands get invoked to build files, but it’s up to the user to write rules that are correct.
- * Users interact with Bazel on a higher level. For example, Bazel has built-in rules for “Java test”, “C++ binary”, and notions such as “target platform” and “host platform”. These rules have been battle tested to be foolproof.
-* Ant and Maven: Ant and Maven are primarily geared toward Java, while Bazel handles multiple languages. Bazel encourages subdividing codebases in smaller reusable units, and can rebuild only ones that need rebuilding. This speeds up development when working with larger codebases.
-* Gradle: Bazel configuration files are much more structured than Gradle’s, letting Bazel understand exactly what each action does. This allows for more parallelism and better reproducibility.
-* Pants, Buck: Both tools were created and developed by ex-Googlers at Twitter and Foursquare, and Facebook respectively. They have been modeled after Bazel, but their feature sets are different, so they aren’t viable alternatives for us.
-
-## Where did Bazel come from?
-
-Bazel is a flavor of the tool that Google uses to build its server software internally. It has expanded to build other software as well, like mobile apps (iOS, Android) that connect to our servers.
-
-## Did you rewrite your internal tool as open-source? Is it a fork?
-
-Bazel shares most of its code with the internal tool and its rules are used for millions of builds every day.
-
-## Why did Google build Bazel?
-
-A long time ago, Google built its software using large, generated Makefiles. These led to slow and unreliable builds, which began to interfere with our developers’ productivity and the company’s agility. Bazel was a way to solve these problems.
-
-## Does Bazel require a build cluster?
-
-Bazel runs build operations locally by default. However, Bazel can also connect to a build cluster for even faster builds and tests. See our documentation on [remote execution and caching](/remote/rbe) and [remote caching](/remote/caching) for further details.
-
-## How does the Google development process work?
-
-For our server code base, we use the following development workflow:
-
-* All our server code is in a single, gigantic version control system.
-* Everybody builds their software with Bazel.
-* Different teams own different parts of the source tree, and make their components available as `BUILD` targets.
-* Branching is primarily used for managing releases, so everybody develops their software at the head revision.
-
-Bazel is a cornerstone of this philosophy: since Bazel requires all dependencies to be fully specified, we can predict which programs and tests are affected by a change, and vet them before submission.
-
-More background on the development process at Google can be found on the [eng tools blog](http://google-engtools.blogspot.com/).
-
-## Why did you open up Bazel?
-
-Building software should be fun and easy. Slow and unpredictable builds take the fun out of programming.
-
-## Why would I want to use Bazel?
-
-* Bazel may give you faster build times because it can recompile only the files that need to be recompiled. Similarly, it can skip re-running tests that it knows haven’t changed.
-* Bazel produces deterministic results. This eliminates skew between incremental and clean builds, laptop and CI system, etc.
-* Bazel can build different client and server apps with the same tool from the same workspace. For example, you can change a client/server protocol in a single commit, and test that the updated mobile app works with the updated server, building both with the same tool, reaping all the aforementioned benefits of Bazel.
-
-## Can I see examples?
-
-Yes; see a [simple example](https://github.com/bazelbuild/bazel/blob/master/examples/cpp/BUILD)
-or read the [Bazel source code](https://github.com/bazelbuild/bazel/blob/master/src/BUILD) for a more complex example.
-
-
-## What is Bazel best at?
-
-Bazel shines at building and testing projects with the following properties:
-
-* Projects with a large codebase
-* Projects written in (multiple) compiled languages
-* Projects that deploy on multiple platforms
-* Projects that have extensive tests
-
-## Where can I run Bazel?
-
-Bazel runs on Linux, macOS (OS X), and Windows.
-
-Porting to other UNIX platforms should be relatively easy, as long as a JDK is available for the platform.
-
-## What should I not use Bazel for?
-
-* Bazel tries to be smart about caching. This means that it is not good for running build operations whose outputs should not be cached. For example, the following steps should not be run from Bazel:
- * A compilation step that fetches data from the internet.
- * A test step that connects to the QA instance of your site.
- * A deployment step that changes your site’s cloud configuration.
-* If your build consists of a few long, sequential steps, Bazel may not be able to help much. You’ll get more speed by breaking long steps into smaller, discrete targets that Bazel can run in parallel.
-
-## How stable is Bazel’s feature set?
-
-The core features (C++, Java, and shell rules) have extensive use inside Google, so they are thoroughly tested and have very little churn. Similarly, we test new versions of Bazel across hundreds of thousands of targets every day to find regressions, and we release new versions multiple times every month.
-
-In short, except for features marked as experimental, Bazel should Just Work. Changes to non-experimental rules will be backward compatible. A more detailed list of feature support statuses can be found in our [support document](/contribute/support).
-
-## How stable is Bazel as a binary?
-
-Inside Google, we make sure that Bazel crashes are very rare. This should also hold for our open source codebase.
-
-## How can I start using Bazel?
-
-See [Getting Started](/start/).
-
-## Doesn’t Docker solve the reproducibility problems?
-
-With Docker you can easily create sandboxes with fixed OS releases, for example, Ubuntu 12.04, Fedora 21. This solves the problem of reproducibility for the system environment – that is, “which version of /usr/bin/c++ do I need?”
-
-Docker does not address reproducibility with regard to changes in the source code. Running Make with an imperfectly written Makefile inside a Docker container can still yield unpredictable results.
-
-Inside Google, we check tools into source control for reproducibility. In this way, we can vet changes to tools (“upgrade GCC to 4.6.1”) with the same mechanism as changes to base libraries (“fix bounds check in OpenSSL”).
-
-## Can I build binaries for deployment on Docker?
-
-With Bazel, you can build standalone, statically linked binaries in C/C++, and self-contained jar files for Java. These run with few dependencies on normal UNIX systems, and as such should be simple to install inside a Docker container.
-
-Bazel has conventions for structuring more complex programs, for example, a Java program that consumes a set of data files, or runs another program as subprocess. It is possible to package up such environments as standalone archives, so they can be deployed on different systems, including Docker images.
-
-## Can I build Docker images with Bazel?
-
-Yes, you can use our [Docker rules](https://github.com/bazelbuild/rules_docker) to build reproducible Docker images.
-
-## Will Bazel make my builds reproducible automatically?
-
-For Java and C++ binaries, yes, assuming you do not change the toolchain. If you have build steps that involve custom recipes (for example, executing binaries through a shell script inside a rule), you will need to take some extra care:
-
-* Do not use dependencies that were not declared. Sandboxed execution (–spawn\_strategy=sandboxed, only on Linux) can help find undeclared dependencies.
-* Avoid storing timestamps and user-IDs in generated files. ZIP files and other archives are especially prone to this.
-* Avoid connecting to the network. Sandboxed execution can help here too.
-* Avoid processes that use random numbers, in particular, dictionary traversal is randomized in many programming languages.
-
-## Do you have binary releases?
-
-Yes, you can find the latest [release binaries](https://github.com/bazelbuild/bazel/releases/latest) and review our [release policy](/release/)
-
-## I use Eclipse/IntelliJ/XCode. How does Bazel interoperate with IDEs?
-
-For IntelliJ, check out the [IntelliJ with Bazel plugin](https://ij.bazel.build/).
-
-For XCode, check out [Tulsi](http://tulsi.bazel.build/).
-
-For Eclipse, check out [E4B plugin](https://github.com/bazelbuild/e4b).
-
-For other IDEs, check out the [blog post](https://blog.bazel.build/2016/06/10/ide-support.html) on how these plugins work.
-
-## I use Jenkins/CircleCI/TravisCI. How does Bazel interoperate with CI systems?
-
-Bazel returns a non-zero exit code if the build or test invocation fails, and this should be enough for basic CI integration. Since Bazel does not need clean builds for correctness, the CI system should not be configured to clean before starting a build/test run.
-
-Further details on exit codes are in the [User Manual](/docs/user-manual).
-
-## What future features can we expect in Bazel?
-
-See our [Roadmaps](/about/roadmap).
-
-## Can I use Bazel for my INSERT LANGUAGE HERE project?
-
-Bazel is extensible. Anyone can add support for new languages. Many languages are supported: see the [build encyclopedia](/reference/be/overview) for a list of recommendations and [awesomebazel.com](https://awesomebazel.com/) for a more comprehensive list.
-
-If you would like to develop extensions or learn how they work, see the documentation for [extending Bazel](/extending/concepts).
-
-## Can I contribute to the Bazel code base?
-
-See our [contribution guidelines](/contribute/).
-
-## Why isn’t all development done in the open?
-
-We still have to refactor the interfaces between the public code in Bazel and our internal extensions frequently. This makes it hard to do much development in the open.
-
-## Are you done open sourcing Bazel?
-
-Open sourcing Bazel is a work-in-progress. In particular, we’re still working on open sourcing:
-
-* Many of our unit and integration tests (which should make contributing patches easier).
-* Full IDE integration.
-
-Beyond code, we’d like to eventually have all code reviews, bug tracking, and design decisions happen publicly, with the Bazel community involved. We are not there yet, so some changes will simply appear in the Bazel repository without clear explanation. Despite this lack of transparency, we want to support external developers and collaborate. Thus, we are opening up the code, even though some of the development is still happening internal to Google. Please let us know if anything seems unclear or unjustified as we transition to an open model.
-
-## Are there parts of Bazel that will never be open sourced?
-
-Yes, some of the code base either integrates with Google-specific technology or we have been looking for an excuse to get rid of (or is some combination of the two). These parts of the code base are not available on GitHub and probably never will be.
-
-## How do I contact the team?
-
-We are reachable at bazel-discuss@googlegroups.com.
-
-## Where do I report bugs?
-
-Open an issue [on GitHub](https://github.com/bazelbuild/bazel/issues).
-
-## What’s up with the word “Blaze” in the codebase?
-
-This is an internal name for the tool. Please refer to Blaze as Bazel.
-
-## Why do other Google projects (Android, Chrome) use other build tools?
-
-Until the first (Alpha) release, Bazel was not available externally, so open source projects such as Chromium and Android could not use it. In addition, the original lack of Windows support was a problem for building Windows applications, such as Chrome. Since the project has matured and become more stable, the [Android Open Source Project](https://source.android.com/) is in the process of migrating to Bazel.
-
-## How do you pronounce “Bazel”?
-
-The same way as “basil” (the herb) in US English: “BAY-zel”. It rhymes with “hazel”. IPA: /ˈbeɪzˌəl/
diff --git a/8.0.1/about/intro.mdx b/8.0.1/about/intro.mdx
deleted file mode 100644
index a531ac2..0000000
--- a/8.0.1/about/intro.mdx
+++ /dev/null
@@ -1,111 +0,0 @@
----
-title: 'Intro to Bazel'
----
-
-
-
-Bazel is an open-source build and test tool similar to Make, Maven, and Gradle.
-It uses a human-readable, high-level build language. Bazel supports projects in
-multiple languages and builds outputs for multiple platforms. Bazel supports
-large codebases across multiple repositories, and large numbers of users.
-
-## Benefits
-
-Bazel offers the following advantages:
-
-* **High-level build language.** Bazel uses an abstract, human-readable
- language to describe the build properties of your project at a high
- semantical level. Unlike other tools, Bazel operates on the *concepts*
- of libraries, binaries, scripts, and data sets, shielding you from the
- complexity of writing individual calls to tools such as compilers and
- linkers.
-
-* **Bazel is fast and reliable.** Bazel caches all previously done work and
- tracks changes to both file content and build commands. This way, Bazel
- knows when something needs to be rebuilt, and rebuilds only that. To further
- speed up your builds, you can set up your project to build in a highly
- parallel and incremental fashion.
-
-* **Bazel is multi-platform.** Bazel runs on Linux, macOS, and Windows. Bazel
- can build binaries and deployable packages for multiple platforms, including
- desktop, server, and mobile, from the same project.
-
-* **Bazel scales.** Bazel maintains agility while handling builds with 100k+
- source files. It works with multiple repositories and user bases in the tens
- of thousands.
-
-* **Bazel is extensible.** Many [languages](/rules) are
- supported, and you can extend Bazel to support any other language or
- framework.
-
-## Using Bazel
-
-To build or test a project with Bazel, you typically do the following:
-
-1. **Set up Bazel.** Download and [install Bazel](/install).
-
-2. **Set up a project [workspace](/concepts/build-ref#workspaces)**, which is a
- directory where Bazel looks for build inputs and `BUILD` files, and where it
- stores build outputs.
-
-3. **Write a `BUILD` file**, which tells Bazel what to build and how to
- build it.
-
- You write your `BUILD` file by declaring build targets using
- [Starlark](/rules/language), a domain-specific language. (See example
- [here](https://github.com/bazelbuild/bazel/blob/master/examples/cpp/BUILD).)
-
- A build target specifies a set of input artifacts that Bazel will build plus
- their dependencies, the build rule Bazel will use to build it, and options
- that configure the build rule.
-
- A build rule specifies the build tools Bazel will use, such as compilers and
- linkers, and their configurations. Bazel ships with a number of build rules
- covering the most common artifact types in the supported languages on
- supported platforms.
-
-4. **Run Bazel** from the [command line](/reference/command-line-reference). Bazel
- places your outputs within the workspace.
-
-In addition to building, you can also use Bazel to run
-[tests](/reference/test-encyclopedia) and [query](/query/guide) the build
-to trace dependencies in your code.
-
-## Bazel build process
-
-When running a build or a test, Bazel does the following:
-
-1. **Loads** the `BUILD` files relevant to the target.
-
-2. **Analyzes** the inputs and their
- [dependencies](/concepts/dependencies), applies the specified build
- rules, and produces an [action](/extending/concepts#evaluation-model)
- graph.
-
-3. **Executes** the build actions on the inputs until the final build outputs
- are produced.
-
-Since all previous build work is cached, Bazel can identify and reuse cached
-artifacts and only rebuild or retest what's changed. To further enforce
-correctness, you can set up Bazel to run builds and tests
-[hermetically](/basics/hermeticity) through sandboxing, minimizing skew
-and maximizing [reproducibility](/run/build#correct-incremental-rebuilds).
-
-### Action graph
-
-The action graph represents the build artifacts, the relationships between them,
-and the build actions that Bazel will perform. Thanks to this graph, Bazel can
-[track](/run/build#build-consistency) changes to
-file content as well as changes to actions, such as build or test commands, and
-know what build work has previously been done. The graph also enables you to
-easily [trace dependencies](/query/guide) in your code.
-
-## Getting started tutorials
-
-To get started with Bazel, see [Getting Started](/start/) or jump
-directly to the Bazel tutorials:
-
-* [Tutorial: Build a C++ Project](/start/cpp)
-* [Tutorial: Build a Java Project](/start/java)
-* [Tutorial: Build an Android Application](/start/android-app)
-* [Tutorial: Build an iOS Application](/start/ios-app)
diff --git a/8.0.1/about/roadmap.mdx b/8.0.1/about/roadmap.mdx
deleted file mode 100644
index 2e18b78..0000000
--- a/8.0.1/about/roadmap.mdx
+++ /dev/null
@@ -1,147 +0,0 @@
----
-title: 'Bazel roadmap'
----
-
-
-
-## Overview
-
-As the Bazel project continues to evolve in response to your needs, we want to
-share our 2024 update.
-
-This roadmap describes current initiatives and predictions for the future of
-Bazel development, giving you visibility into current priorities and ongoing
-projects.
-
-## Bazel 8.0 Release
-
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
-The following features are planned to be implemented.
-
-### Bzlmod: external dependency management system
-
-[Bzlmod](https://bazel.build/docs/bzlmod) automatically resolves transitive
-dependencies, allowing projects to scale while staying fast and
-resource-efficient.
-
-With Bazel 8, we will disable WORKSPACE support by default (it will still be
-possible to enable it using `--enable_workspace`); with Bazel 9 WORKSPACE
-support will be removed. Starting with Bazel 7.1, you can set
-`--noenable_workspace` to opt into the new behavior.
-
-Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
-functionality, including:
-
-* The new flag `--enable_workspace` can be set to `false` to completely
- disable WORKSPACE functionality.
-* New directory watching API (see
- [#21435](https://github.com/bazelbuild/bazel/pull/21435), shipped in Bazel
- 7.1).
-* Improved scheme for generating canonical repository names for better
- cacheability of actions across dependency version updates.
- ([#21316](https://github.com/bazelbuild/bazel/pull/21316), shipped in Bazel
- 7.1)
-* An improved shared repository cache (see
- [#12227](https://github.com/bazelbuild/bazel/issues/12227)).
-* Vendor and offline mode support — allows users to run builds with
- pre-downloaded dependencies (see
- [#19563](https://github.com/bazelbuild/bazel/issues/19563)).
-* Reduced merge conflicts in lock files
- ([#20396](https://github.com/bazelbuild/bazel/issues/20369)).
-* Segmented MODULE.bazel
- ([#17880](https://github.com/bazelbuild/bazel/issues/17880))
-* Allow overriding module extension generated repository
- ([#19301](https://github.com/bazelbuild/bazel/issues/19301))
-* Improved documentation (e.g.
- [#18030](https://github.com/bazelbuild/bazel/issues/18030),
- [#15821](https://github.com/bazelbuild/bazel/issues/15821)) and migration
- guide and migration tooling.
-
-### Remote execution improvements
-
-* Add support for asynchronous execution, speeding up remote execution by
- increased parallelism with flag `--jobs`.
-* Make it easier to debug cache misses by a new compact execution log,
- reducing its size by 100x and its runtime overhead significantly (see
- [#18643](https://github.com/bazelbuild/bazel/issues/18643)).
-* Implement garbage collection for the disk cache (see
- [#5139](https://github.com/bazelbuild/bazel/issues/5139)).
-* Implement remote output service to allow lazy downloading of arbitrary build
- outputs (see
- [#20933](https://github.com/bazelbuild/bazel/discussions/20933)).
-
-### Migration of Android, C++, Java, Python, and Proto rules
-
-Complete migration of Android, C++, Java, and Python rulesets to dedicated
-repositories and decoupling them from the Bazel releases. This effort allows
-Bazel users and rule authors to
-
-* Update rules independently of Bazel.
-* Update and customize rules as needed.
-
-The new location of the rulesets is going to be `bazelbuild/rules_android`,
-`rules_cc`, `rules_java`, `rules_python` and `google/protobuf`. `rules_proto` is
-going to be deprecated.
-
-Bazel 8 will provide a temporary migration flag that will automatically use the
-rulesets that were previously part of the binary from their repositories. All
-the users of those rulesets are expected to eventually depend on their
-repositories and load them similarly to other rulesets that were never part of
-Bazel.
-
-Bazel 8 will also improve on the existing extending rules and subrule APIs and
-mark them as non-experimental.
-
-### Starlark improvements
-
-* Symbolic Macros are a new way of writing macros that is friendlier to
- `BUILD` users, macro authors, and tooling. Compared to legacy macros, which
- Bazel has only limited insight into, symbolic macros help users avoid common
- pitfalls and enforce best practices.
-* Package finalizers are a proposed feature for adding first-class support for
- custom package validation logic. They are intended to help us deprecate
- `native.existing_rules()`.
-
-### Configurability
-
-* Output path mapping continues to stabilize: promising better remote cache
- performance and build speed for rule designers who use transitions.
-* Automatically set build flags suitable for a given `--platforms`.
-* Define project-supported flag combinations and automatically build targets
- with default flags without having to set bazelrcs.
-* Don't redo build analysis every time build flags change.
-
-### Project Skyfocus - minimize retained data structures
-
-Bazel holds a lot of state in RAM for fast incremental builds. However,
-developers often change a small subset of the source files (e.g. almost never
-one of the external dependencies). With Skyfocus, Bazel will provide an
-experimental way to drop unnecessary incremental state and reduce Bazel's memory
-footprint, while still providing the same fast incremental build experience.
-
-The initial scope aims to improve the retained heap metric only. Peak heap
-reduction is a possibility, but not included in the initial scope.
-
-### Misc
-
-* Mobile install v3, a simpler and better maintained approach to incrementally
- deploy Android applications.
-* Garbage collection for repository caches and Bazel's `install_base`.
-* Reduced sandboxing overhead.
-
-### Bazel-JetBrains* IntelliJ IDEA support
-
-Incremental IntelliJ plugin updates to support the latest JetBrains plugin
-release.
-
-*This roadmap snapshots targets, and should not be taken as guarantees.
-Priorities are subject to change in response to developer and customer
-feedback, or new market opportunities.*
-
-*To be notified of new features — including updates to this roadmap — join the
-[Google Group](https://groups.google.com/g/bazel-discuss) community.*
-
-*Copyright © 2022 JetBrains s.r.o. JetBrains and IntelliJ are registered trademarks of JetBrains s.r.o
diff --git a/8.0.1/about/vision.mdx b/8.0.1/about/vision.mdx
deleted file mode 100644
index da0ed02..0000000
--- a/8.0.1/about/vision.mdx
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: 'Bazel Vision'
----
-
-
-
-Any software developer can efficiently build, test, and package
-any project, of any size or complexity, with tooling that's easy to adopt and
-extend.
-
-* **Engineers can take build fundamentals for granted.** Software developers
- focus on the creative process of authoring code because the mechanical
- process of build and test is solved. When customizing the build system to
- support new languages or unique organizational needs, users focus on the
- aspects of extensibility that are unique to their use case, without having
- to reinvent the basic plumbing.
-
-* **Engineers can easily contribute to any project.** A developer who wants to
- start working on a new project can simply clone the project and run the
- build. There's no need for local configuration - it just works. With
- cross-platform remote execution, they can work on any machine anywhere and
- fully test their changes against all platforms the project targets.
- Engineers can quickly configure the build for a new project or incrementally
- migrate an existing build.
-
-* **Projects can scale to any size codebase, any size team.** Fast,
- incremental testing allows teams to fully validate every change before it is
- committed. This remains true even as repos grow, projects span multiple
- repos, and multiple languages are introduced. Infrastructure does not force
- developers to trade test coverage for build speed.
-
-**We believe Bazel has the potential to fulfill this vision.**
-
-Bazel was built from the ground up to enable builds that are reproducible (a
-given set of inputs will always produce the same outputs) and portable (a build
-can be run on any machine without affecting the output).
-
-These characteristics support safe incrementality (rebuilding only changed
-inputs doesn't introduce the risk of corruption) and distributability (build
-actions are isolated and can be offloaded). By minimizing the work needed to do
-a correct build and parallelizing that work across multiple cores and remote
-systems, Bazel can make any build fast.
-
-Bazel's abstraction layer — instructions specific to languages, platforms, and
-toolchains implemented in a simple extensibility language — allows it to be
-easily applied to any context.
-
-## Bazel core competencies
-
-1. Bazel supports **multi-language, multi-platform** builds and tests. You can
- run a single command to build and test your entire source tree, no matter
- which combination of languages and platforms you target.
-1. Bazel builds are **fast and correct**. Every build and test run is
- incremental, on your developers' machines and on CI.
-1. Bazel provides a **uniform, extensible language** to define builds for any
- language or platform.
-1. Bazel allows your builds **to scale** by connecting to remote execution and
- caching services.
-1. Bazel works across **all major development platforms** (Linux, MacOS, and
- Windows).
-1. We accept that adopting Bazel requires effort, but **gradual adoption** is
- possible. Bazel interfaces with de-facto standard tools for a given
- language/platform.
-
-## Serving language communities
-
-Software engineering evolves in the context of language communities — typically,
-self-organizing groups of people who use common tools and practices.
-
-To be of use to members of a language community, high-quality Bazel rules must be
-available that integrate with the workflows and conventions of that community.
-
-Bazel is committed to be extensible and open, and to support good rulesets for
-any language.
-
-### Requirements of a good ruleset
-
-1. The rules need to support efficient **building and testing** for the
- language, including code coverage.
-1. The rules need to **interface with a widely-used "package manager"** for the
- language (such as Maven for Java), and support incremental migration paths
- from other widely-used build systems.
-1. The rules need to be **extensible and interoperable**, following
- ["Bazel sandwich"](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-08-04-extensibility-for-native-rules.md)
- principles.
-1. The rules need to be **remote-execution ready**. In practice, this means
- **configurable using the [toolchains](/extending/toolchains) mechanism**.
-1. The rules (and Bazel) need to interface with a **widely-used IDE** for the
- language, if there is one.
-1. The rules need to have **thorough, usable documentation,** with introductory
- material for new users, comprehensive docs for expert users.
-
-Each of these items is essential and only together do they deliver on Bazel's
-competencies for their particular ecosystem.
-
-They are also, by and large, sufficient - once all are fulfilled, Bazel fully
-delivers its value to members of that language community.
diff --git a/8.0.1/about/why.mdx b/8.0.1/about/why.mdx
deleted file mode 100644
index 97cfa36..0000000
--- a/8.0.1/about/why.mdx
+++ /dev/null
@@ -1,85 +0,0 @@
----
-title: 'Why Bazel?'
----
-
-
-
-Bazel is a [fast](#fast), [correct](#correct), and [extensible](#extensible)
-build tool with [integrated testing](#integrated-testing) that supports multiple
-[languages](#multi-language), [repositories](#multi-repository), and
-[platforms](#multi-platform) in an industry-leading [ecosystem](#ecosystem).
-
-## Bazel is fast
-
-Bazel knows exactly what input files each build command needs, avoiding
-unnecessary work by re-running only when the set of input files have
-changed between each build.
-It runs build commands with as much parallelism as possible, either within the
-same computer or on [remote build nodes](/remote/rbe). If the structure of build
-allows for it, it can run thousands of build or test commands at the same time.
-
-This is supported by multiple caching layers, in memory, on disk and on the
-remote build farm, if available. At Google, we routinely achieve cache hit rates
-north of 99%.
-
-## Bazel is correct
-
-Bazel ensures that your binaries are built *only* from your own
-source code. Bazel actions run in individual sandboxes and Bazel tracks
-every input file of the build, only and always re-running build
-commands when it needs to. This keeps your binaries up-to-date so that the
-[same source code always results in the same binary](/basics/hermeticity), bit
-by bit.
-
-Say goodbyte to endless `make clean` invocations and to chasing phantom bugs
-that were in fact resolved in source code that never got built.
-
-## Bazel is extensible
-
-Harness the full power of Bazel by writing your own rules and macros to
-customize Bazel for your specific needs across a wide range of projects.
-
-Bazel rules are written in [Starlark](/rules/language), our
-in-house programming language that's a subset of Python. Starlark makes
-rule-writing accessible to most developers, while also creating rules that can
-be used across the ecosystem.
-
-## Integrated testing
-
-Bazel's [integrated test runner](/docs/user-manual#running-tests)
-knows and runs only those tests needing to be re-run, using remote execution
-(if available) to run them in parallel. Detect flakes early by using remote
-execution to quickly run a test thousands of times.
-
-Bazel [provides facilities](/remote/bep) to upload test results to a central
-location, thereby facilitating efficient communication of test outcomes, be it
-on CI or by individual developers.
-
-## Multi-language support
-
-Bazel supports many common programming languages including C++, Java,
-Kotlin, Python, Go, and Rust. You can build multiple binaries (for example,
-backend, web UI and mobile app) in the same Bazel invocation without being
-constrained to one language's idiomatic build tool.
-
-## Multi-repository support
-
-Bazel can [gather source code from multiple locations](/external/overview): you
-don't need to vendor your dependencies (but you can!), you can instead point
-Bazel to the location of your source code or prebuilt artifacts (e.g. a git
-repository or Maven Central), and it takes care of the rest.
-
-## Multi-platform support
-
-Bazel can simultaneously build projects for multiple platforms including Linux,
-macOS, Windows, and Android. It also provides powerful
-[cross-compilation capabilities](/extending/platforms) to build code for one
-platform while running the build on another.
-
-## Wide ecosystem
-
-[Industry leaders](/community/users) love Bazel, building a large
-community of developers who use and contribute to Bazel. Find a tools, services
-and documentation, including [consulting and SaaS offerings](/community/experts)
-Bazel can use. Explore extensions like support for programming languages in
-our [open source software repositories](/rules).
diff --git a/8.0.1/advanced/performance/build-performance-breakdown.mdx b/8.0.1/advanced/performance/build-performance-breakdown.mdx
deleted file mode 100644
index 477e757..0000000
--- a/8.0.1/advanced/performance/build-performance-breakdown.mdx
+++ /dev/null
@@ -1,235 +0,0 @@
----
-title: 'Breaking down build performance'
----
-
-
-
-Bazel is complex and does a lot of different things over the course of a build,
-some of which can have an impact on build performance. This page attempts to map
-some of these Bazel concepts to their implications on build performance. While
-not extensive, we have included some examples of how to detect build performance
-issues through [extracting metrics](/configure/build-performance-metrics)
-and what you can do to fix them. With this, we hope you can apply these concepts
-when investigating build performance regressions.
-
-### Clean vs Incremental builds
-
-A clean build is one that builds everything from scratch, while an incremental
-build reuses some already completed work.
-
-We suggest looking at clean and incremental builds separately, especially when
-you are collecting / aggregating metrics that are dependent on the state of
-Bazel’s caches (for example
-[build request size metrics](#deterministic-build-metrics-as-a-proxy-for-build-performance)
-). They also represent two different user experiences. As compared to starting
-a clean build from scratch (which takes longer due to a cold cache), incremental
-builds happen far more frequently as developers iterate on code (typically
-faster since the cache is usually already warm).
-
-You can use the `CumulativeMetrics.num_analyses` field in the BEP to classify
-builds. If `num_analyses <= 1`, it is a clean build; otherwise, we can broadly
-categorize it to likely be an incremental build - the user could have switched
-to different flags or different targets causing an effectively clean build. Any
-more rigorous definition of incrementality will likely have to come in the form
-of a heuristic, for example looking at the number of packages loaded
-(`PackageMetrics.packages_loaded`).
-
-### Deterministic build metrics as a proxy for build performance
-
-Measuring build performance can be difficult due to the non-deterministic nature
-of certain metrics (for example Bazel’s CPU time or queue times on a remote
-cluster). As such, it can be useful to use deterministic metrics as a proxy for
-the amount of work done by Bazel, which in turn affects its performance.
-
-The size of a build request can have a significant implication on build
-performance. A larger build could represent more work in analyzing and
-constructing the build graphs. Organic growth of builds comes naturally with
-development, as more dependencies are added/created, and thus grow in complexity
-and become more expensive to build.
-
-We can slice this problem into the various build phases, and use the following
-metrics as proxy metrics for work done at each phase:
-
-1. `PackageMetrics.packages_loaded`: the number of packages successfully loaded.
- A regression here represents more work that needs to be done to read and parse
- each additional BUILD file in the loading phase.
- - This is often due to the addition of dependencies and having to load their
- transitive closure.
- - Use [query](/query/quickstart) / [cquery](/query/cquery) to find
- where new dependencies might have been added.
-
-2. `TargetMetrics.targets_configured`: representing the number of targets and
- aspects configured in the build. A regression represents more work in
- constructing and traversing the configured target graph.
- - This is often due to the addition of dependencies and having to construct
- the graph of their transitive closure.
- - Use [cquery](/query/cquery) to find where new
- dependencies might have been added.
-
-3. `ActionSummary.actions_created`: represents the actions created in the build,
- and a regression represents more work in constructing the action graph. Note
- that this also includes unused actions that might not have been executed.
- - Use [aquery](/query/aquery) for debugging regressions;
- we suggest starting with
- [`--output=summary`](/reference/command-line-reference#flag--output)
- before further drilling down with
- [`--skyframe_state`](/reference/command-line-reference#flag--skyframe_state).
-
-4. `ActionSummary.actions_executed`: the number of actions executed, a
- regression directly represents more work in executing these actions.
- - The [BEP](/remote/bep) writes out the action statistics
- `ActionData` that shows the most executed action types. By default, it
- collects the top 20 action types, but you can pass in the
- [`--experimental_record_metrics_for_all_mnemonics`](/reference/command-line-reference#flag--experimental_record_metrics_for_all_mnemonics)
- to collect this data for all action types that were executed.
- - This should help you to figure out what kind of actions were executed
- (additionally).
-
-5. `BuildGraphSummary.outputArtifactCount`: the number of artifacts created by
- the executed actions.
- - If the number of actions executed did not increase, then it is likely that
- a rule implementation was changed.
-
-
-These metrics are all affected by the state of the local cache, hence you will
-want to ensure that the builds you extract these metrics from are
-**clean builds**.
-
-We have noted that a regression in any of these metrics can be accompanied by
-regressions in wall time, cpu time and memory usage.
-
-### Usage of local resources
-
-Bazel consumes a variety of resources on your local machine (both for analyzing
-the build graph and driving the execution, and for running local actions), this
-can affect the performance / availability of your machine in performing the
-build, and also other tasks.
-
-#### Time spent
-
-Perhaps the metrics most susceptible to noise (and can vary greatly from build
-to build) is time; in particular - wall time, cpu time and system time. You can
-use [bazel-bench](https://github.com/bazelbuild/bazel-bench) to get
-a benchmark for these metrics, and with a sufficient number of `--runs`, you can
-increase the statistical significance of your measurement.
-
-- **Wall time** is the real world time elapsed.
- - If _only_ wall time regresses, we suggest collecting a
- [JSON trace profile](/advanced/performance/json-trace-profile) and looking
- for differences. Otherwise, it would likely be more efficient to
- investigate other regressed metrics as they could have affected the wall
- time.
-
-- **CPU time** is the time spent by the CPU executing user code.
- - If the CPU time regresses across two project commits, we suggest collecting
- a Starlark CPU profile. You should probably also use `--nobuild` to
- restrict the build to the analysis phase since that is where most of the
- CPU heavy work is done.
-
-- System time is the time spent by the CPU in the kernel.
- - If system time regresses, it is mostly correlated with I/O when Bazel reads
- files from your file system.
-
-#### System-wide load profiling
-
-Using the
-[`--experimental_collect_load_average_in_profiler`](https://github.com/bazelbuild/bazel/blob/6.0.0/src/main/java/com/google/devtools/build/lib/runtime/CommonCommandOptions.java#L306-L312)
-flag introduced in Bazel 6.0, the
-[JSON trace profiler](/advanced/performance/json-trace-profile) collects the
-system load average during the invocation.
-
-
-
-**Figure 1.** Profile that includes system load average.
-
-A high load during a Bazel invocation can be an indication that Bazel schedules
-too many local actions in parallel for your machine. You might want to look into
-adjusting
-[`--local_cpu_resources`](/reference/command-line-reference#flag--local_cpu_resources)
-and [`--local_ram_resources`](/reference/command-line-reference#flag--local_ram_resources),
-especially in container environments (at least until
-[#16512](https://github.com/bazelbuild/bazel/pull/16512) is merged).
-
-
-#### Monitoring Bazel memory usage
-
-There are two main sources to get Bazel’s memory usage, Bazel `info` and the
-[BEP](/remote/bep).
-
-- `bazel info used-heap-size-after-gc`: The amount of used memory in bytes after
- a call to `System.gc()`.
- - [Bazel bench](https://github.com/bazelbuild/bazel-bench)
- provides benchmarks for this metric as well.
- - Additionally, there are `peak-heap-size`, `max-heap-size`, `used-heap-size`
- and `committed-heap-size` (see
- [documentation](/docs/user-manual#configuration-independent-data)), but are
- less relevant.
-
-- [BEP](/remote/bep)’s
- `MemoryMetrics.peak_post_gc_heap_size`: Size of the peak JVM heap size in
- bytes post GC (requires setting
- [`--memory_profile`](/reference/command-line-reference#flag--memory_profile)
- that attempts to force a full GC).
-
-A regression in memory usage is usually a result of a regression in
-[build request size metrics](#deterministic_build_metrics_as_a_proxy_for_build_performance),
-which are often due to addition of dependencies or a change in the rule
-implementation.
-
-To analyze Bazel’s memory footprint on a more granular level, we recommend using
-the [built-in memory profiler](/rules/performance#memory-profiling)
-for rules.
-
-#### Memory profiling of persistent workers
-
-While [persistent workers](/remote/persistent) can help to speed up builds
-significantly (especially for interpreted languages) their memory footprint can
-be problematic. Bazel collects metrics on its workers, in particular, the
-`WorkerMetrics.WorkerStats.worker_memory_in_kb` field tells how much memory
-workers use (by mnemonic).
-
-The [JSON trace profiler](/advanced/performance/json-trace-profile) also
-collects persistent worker memory usage during the invocation by passing in the
-[`--experimental_collect_system_network_usage`](https://github.com/bazelbuild/bazel/blob/6.0.0/src/main/java/com/google/devtools/build/lib/runtime/CommonCommandOptions.java#L314-L320)
-flag (new in Bazel 6.0).
-
-
-
-**Figure 2.** Profile that includes workers memory usage.
-
-Lowering the value of
-[`--worker_max_instances`](/reference/command-line-reference#flag--worker_max_instances)
-(default 4) might help to reduce
-the amount of memory used by persistent workers. We are actively working on
-making Bazel’s resource manager and scheduler smarter so that such fine tuning
-will be required less often in the future.
-
-### Monitoring network traffic for remote builds
-
-In remote execution, Bazel downloads artifacts that were built as a result of
-executing actions. As such, your network bandwidth can affect the performance
-of your build.
-
-If you are using remote execution for your builds, you might want to consider
-monitoring the network traffic during the invocation using the
-`NetworkMetrics.SystemNetworkStats` proto from the [BEP](/remote/bep)
-(requires passing `--experimental_collect_system_network_usage`).
-
-Furthermore, [JSON trace profiles](/advanced/performance/json-trace-profile)
-allow you to view system-wide network usage throughout the course of the build
-by passing the `--experimental_collect_system_network_usage` flag (new in Bazel
-6.0).
-
-
-
-**Figure 3.** Profile that includes system-wide network usage.
-
-A high but rather flat network usage when using remote execution might indicate
-that network is the bottleneck in your build; if you are not using it already,
-consider turning on Build without the Bytes by passing
-[`--remote_download_minimal`](/reference/command-line-reference#flag--remote_download_minimal).
-This will speed up your builds by avoiding the download of unnecessary intermediate artifacts.
-
-Another option is to configure a local
-[disk cache](/reference/command-line-reference#flag--disk_cache) to save on
-download bandwidth.
diff --git a/8.0.1/advanced/performance/build-performance-metrics.mdx b/8.0.1/advanced/performance/build-performance-metrics.mdx
deleted file mode 100644
index 8391ea8..0000000
--- a/8.0.1/advanced/performance/build-performance-metrics.mdx
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: 'Extracting build performance metrics'
----
-
-
-
-Probably every Bazel user has experienced builds that were slow or slower than
-anticipated. Improving the performance of individual builds has particular value
-for targets with significant impact, such as:
-
-1. Core developer targets that are frequently iterated on and (re)built.
-
-2. Common libraries widely depended upon by other targets.
-
-3. A representative target from a class of targets (e.g. custom rules),
- diagnosing and fixing issues in one build might help to resolve issues at the
- larger scale.
-
-An important step to improving the performance of builds is to understand where
-resources are spent. This page lists different metrics you can collect.
-[Breaking down build performance](/configure/build-performance-breakdown) showcases
-how you can use these metrics to detect and fix build performance issues.
-
-There are a few main ways to extract metrics from your Bazel builds, namely:
-
-## Build Event Protocol (BEP)
-
-Bazel outputs a variety of protocol buffers
-[`build_event_stream.proto`](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
-through the [Build Event Protocol (BEP)](/remote/bep), which
-can be aggregated by a backend specified by you. Depending on your use cases,
-you might decide to aggregate the metrics in various ways, but here we will go
-over some concepts and proto fields that would be useful in general to consider.
-
-## Bazel’s query / cquery / aquery commands
-
-Bazel provides 3 different query modes ([query](/query/quickstart),
-[cquery](/query/cquery) and [aquery](/query/aquery)) that allow users
-to query the target graph, configured target graph and action graph
-respectively. The query language provides a
-[suite of functions](/query/language#functions) usable across the different
-query modes, that allows you to customize your queries according to your needs.
-
-## JSON Trace Profiles
-
-For every build-like Bazel invocation, Bazel writes a trace profile in JSON
-format. The [JSON trace profile](/advanced/performance/json-trace-profile) can
-be very useful to quickly understand what Bazel spent time on during the
-invocation.
-
-## Execution Log
-
-The [execution log](/remote/cache-remote) can help you to troubleshoot and fix
-missing remote cache hits due to machine and environment differences or
-non-deterministic actions. If you pass the flag
-[`--experimental_execution_log_spawn_metrics`](/reference/command-line-reference#flag--experimental_execution_log_spawn_metrics)
-(available from Bazel 5.2) it will also contain detailed spawn metrics, both for
-locally and remotely executed actions. You can use these metrics for example to
-make comparisons between local and remote machine performance or to find out
-which part of the spawn execution is consistently slower than expected (for
-example due to queuing).
-
-## Execution Graph Log
-
-While the JSON trace profile contains the critical path information, sometimes
-you need additional information on the dependency graph of the executed actions.
-Starting with Bazel 6.0, you can pass the flags
-`--experimental_execution_graph_log` and
-`--experimental_execution_graph_log_dep_type=all` to write out a log about the
-executed actions and their inter-dependencies.
-
-This information can be used to understand the drag that is added by a node on
-the critical path. The drag is the amount of time that can potentially be saved
-by removing a particular node from the execution graph.
-
-The data helps you predict the impact of changes to the build and action graph
-before you actually do them.
-
-## Benchmarking with bazel-bench
-
-[Bazel bench](https://github.com/bazelbuild/bazel-bench) is a
-benchmarking tool for Git projects to benchmark build performance in the
-following cases:
-
-* **Project benchmark:** Benchmarking two git commits against each other at a
- single Bazel version. Used to detect regressions in your build (often through
- the addition of dependencies).
-
-* **Bazel benchmark:** Benchmarking two versions of Bazel against each other at
- a single git commit. Used to detect regressions within Bazel itself (if you
- happen to maintain / fork Bazel).
-
-Benchmarks monitor wall time, CPU time and system time and Bazel’s retained
-heap size.
-
-It is also recommended to run Bazel bench on dedicated, physical machines that
-are not running other processes so as to reduce sources of variability.
diff --git a/8.0.1/advanced/performance/iteration-speed.mdx b/8.0.1/advanced/performance/iteration-speed.mdx
deleted file mode 100644
index 2bbf839..0000000
--- a/8.0.1/advanced/performance/iteration-speed.mdx
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: 'Optimize Iteration Speed'
----
-
-
-
-This page describes how to optimize Bazel's build performance when running Bazel
-repeatedly.
-
-## Bazel's Runtime State
-
-A Bazel invocation involves several interacting parts.
-
-* The `bazel` command line interface (CLI) is the user-facing front-end tool
- and receives commands from the user.
-
-* The CLI tool starts a [*Bazel server*](https://bazel.build/run/client-server)
- for each distinct [output base](https://bazel.build/remote/output-directories).
- The Bazel server is generally persistent, but will shut down after some idle
- time so as to not waste resources.
-
-* The Bazel server performs the loading and analysis steps for a given command
- (`build`, `run`, `cquery`, etc.), in which it constructs the necessary parts
- of the build graph in memory. The resulting data structures are retained in
- the Bazel server as part of the *analysis cache*.
-
-* The Bazel server can also perform the action execution, or it can send
- actions off for remote execution if it is set up to do so. The results of
- action executions are also cached, namely in the *action cache* (or
- *execution cache*, which may be either local or remote, and it may be shared
- among Bazel servers).
-
-* The result of the Bazel invocation is made available in the output tree.
-
-## Running Bazel Iteratively
-
-In a typical developer workflow, it is common to build (or run) a piece of code
-repeatedly, often at a very high frequency (e.g. to resolve some compilation
-error or investigate a failing test). In this situation, it is important that
-repeated invocations of `bazel` have as little overhead as possible relative to
-the underlying, repeated action (e.g. invoking a compiler, or executing a test).
-
-With this in mind, we take another look at Bazel's runtime state:
-
-The analysis cache is a critical piece of data. A significant amount of time can
-be spent just on the loading and analysis phases of a cold run (i.e. a run just
-after the Bazel server was started or when the analysis cache was discarded).
-For a single, successful cold build (e.g. for a production release) this cost is
-bearable, but for repeatedly building the same target it is important that this
-cost be amortized and not repeated on each invocation.
-
-The analysis cache is rather volatile. First off, it is part of the in-process
-state of the Bazel server, so losing the server loses the cache. But the cache
-is also *invalidated* very easily: for example, many `bazel` command line flags
-cause the cache to be discarded. This is because many flags affect the build
-graph (e.g. because of
-[configurable attributes](https://bazel.build/configure/attributes)). Some flag
-changes can also cause the Bazel server to be restarted (e.g. changing
-[startup options](https://bazel.build/docs/user-manual#startup-options)).
-
-A good execution cache is also valuable for build performance. An execution
-cache can be kept locally
-[on disk](https://bazel.build/remote/caching#disk-cache), or
-[remotely](https://bazel.build/remote/caching). The cache can be shared among
-Bazel servers, and indeed among developers.
-
-## Avoid discarding the analysis cache
-
-Bazel will print a warning if either the analysis cache was discarded or the
-server was restarted. Either of these should be avoided during iterative use:
-
-* Be mindful of changing `bazel` flags in the middle of an iterative
- workflow. For example, mixing a `bazel build -c opt` with a `bazel cquery`
- causes each command to discard the analysis cache of the other. In general,
- try to use a fixed set of flags for the duration of a particular workflow.
-
-* Losing the Bazel server loses the analysis cache. The Bazel server has a
- [configurable](https://bazel.build/docs/user-manual#max-idle-secs) idle
- time, after which it shuts down. You can configure this time via your
- bazelrc file to suit your needs. The server also restarted when startup
- flags change, so, again, avoid changing those flags if possible.
-
-* Beware that the Bazel server is killed if you press
- Ctrl-C repeatedly while Bazel is running. It is tempting to try to save time
- by interrupting a running build that is no longer needed, but only press
- Ctrl-C once to request a graceful end of the current invocation.
-
-* If you want to use multiple sets of flags from the same workspace, you can
- use multiple, distinct output bases, switched with the `--output_base`
- flag. Each output base gets its own Bazel server.
-
-To make this condition an error rather than a warning, you can use the
-`--noallow_analysis_cache_discard` flag (introduced in Bazel 6.4.0)
diff --git a/8.0.1/advanced/performance/json-trace-profile.mdx b/8.0.1/advanced/performance/json-trace-profile.mdx
deleted file mode 100644
index 56e278c..0000000
--- a/8.0.1/advanced/performance/json-trace-profile.mdx
+++ /dev/null
@@ -1,200 +0,0 @@
----
-title: 'JSON Trace Profile'
----
-
-
-
-The JSON trace profile can be very useful to quickly understand what Bazel spent
-time on during the invocation.
-
-By default, for all build-like commands and query, Bazel writes a profile into
-the output base named `command-$INOVCATION_ID.profile.gz`, where
-`$INOVCATION_ID` is the invocation identifier of the command. Bazel also creates
-a symlink called `command.profile.gz` in the output base that points the profile
-of the latest command. You can configure whether a profile is written with the
-[`--generate_json_trace_profile`](/reference/command-line-reference#flag--generate_json_trace_profile)
-flag, and the location it is written to with the
-[`--profile`](/docs/user-manual#profile) flag. Locations ending with `.gz` are
-compressed with GZIP. Bazel keeps the last 5 profiles, configurable by
-[`--profiles_to_retain`](/reference/command-line-reference#flag--generate_json_trace_profile),
-in the output base by default for post-build analysis. Explicitly passing a
-profile path with `--profile` disables automatic garbage collection.
-
-## Tools
-
-You can load this profile into `chrome://tracing` or analyze and
-post-process it with other tools.
-
-### `chrome://tracing`
-
-To visualize the profile, open `chrome://tracing` in a Chrome browser tab,
-click "Load" and pick the (potentially compressed) profile file. For more
-detailed results, click the boxes in the lower left corner.
-
-Example profile:
-
-
-
-**Figure 1.** Example profile.
-
-You can use these keyboard controls to navigate:
-
-* Press `1` for "select" mode. In this mode, you can select
- particular boxes to inspect the event details (see lower left corner).
- Select multiple events to get a summary and aggregated statistics.
-* Press `2` for "pan" mode. Then drag the mouse to move the view. You
- can also use `a`/`d` to move left/right.
-* Press `3` for "zoom" mode. Then drag the mouse to zoom. You can
- also use `w`/`s` to zoom in/out.
-* Press `4` for "timing" mode where you can measure the distance
- between two events.
-* Press `?` to learn about all controls.
-
-### `bazel analyze-profile`
-
-The Bazel subcommand [`analyze-profile`](/docs/user-manual#analyze-profile)
-consumes a profile format and prints cumulative statistics for
-different task types for each build phase and an analysis of the critical path.
-
-For example, the commands
-
-```
-$ bazel build --profile=/tmp/profile.gz //path/to:target
-...
-$ bazel analyze-profile /tmp/profile.gz
-```
-
-may yield output of this form:
-
-```
-INFO: Profile created on Tue Jun 16 08:59:40 CEST 2020, build ID: 0589419c-738b-4676-a374-18f7bbc7ac23, output base: /home/johndoe/.cache/bazel/_bazel_johndoe/d8eb7a85967b22409442664d380222c0
-
-=== PHASE SUMMARY INFORMATION ===
-
-Total launch phase time 1.070 s 12.95%
-Total init phase time 0.299 s 3.62%
-Total loading phase time 0.878 s 10.64%
-Total analysis phase time 1.319 s 15.98%
-Total preparation phase time 0.047 s 0.57%
-Total execution phase time 4.629 s 56.05%
-Total finish phase time 0.014 s 0.18%
-------------------------------------------------
-Total run time 8.260 s 100.00%
-
-Critical path (4.245 s):
- Time Percentage Description
- 8.85 ms 0.21% _Ccompiler_Udeps for @local_config_cc// compiler_deps
- 3.839 s 90.44% action 'Compiling external/com_google_protobuf/src/google/protobuf/compiler/php/php_generator.cc [for host]'
- 270 ms 6.36% action 'Linking external/com_google_protobuf/protoc [for host]'
- 0.25 ms 0.01% runfiles for @com_google_protobuf// protoc
- 126 ms 2.97% action 'ProtoCompile external/com_google_protobuf/python/google/protobuf/compiler/plugin_pb2.py'
- 0.96 ms 0.02% runfiles for //tools/aquery_differ aquery_differ
-```
-
-### Bazel Invocation Analyzer
-
-The open-source
-[Bazel Invocation Analyzer](https://github.com/EngFlow/bazel_invocation_analyzer)
-consumes a profile format and prints suggestions on how to improve
-the build’s performance. This analysis can be performed using its CLI or on
-[https://analyzer.engflow.com](https://analyzer.engflow.com).
-
-### `jq`
-
-`jq` is like `sed` for JSON data. An example usage of `jq` to extract all
-durations of the sandbox creation step in local action execution:
-
-```
-$ zcat $(../bazel-6.0.0rc1-linux-x86_64 info output_base)/command.profile.gz | jq '.traceEvents | .[] | select(.name == "sandbox.createFileSystem") | .dur'
-6378
-7247
-11850
-13756
-6555
-7445
-8487
-15520
-[...]
-```
-
-## Profile information
-
-The profile contains multiple rows. Usually the bulk of rows represent Bazel
-threads and their corresponding events, but some special rows are also included.
-
-The special rows included depend on the version of Bazel invoked when the
-profile was created, and may be customized by different flags.
-
-Figure 1 shows a profile created with Bazel v5.3.1 and includes these rows:
-
-* `action count`: Displays how many concurrent actions were in flight. Click
- on it to see the actual value. Should go up to the value of
- [`--jobs`](/reference/command-line-reference#flag--jobs) in clean
- builds.
-* `CPU usage (Bazel)`: For each second of the build, displays the amount of
- CPU that was used by Bazel (a value of 1 equals one core being 100% busy).
-* `Critical Path`: Displays one block for each action on the critical path.
-* `Main Thread`: Bazel’s main thread. Useful to get a high-level picture of
- what Bazel is doing, for example "Launch Blaze", "evaluateTargetPatterns",
- and "runAnalysisPhase".
-* `Garbage Collector`: Displays minor and major Garbage Collection (GC)
- pauses.
-
-## Common performance issues
-
-When analyzing performance profiles, look for:
-
-* Slower than expected analysis phase (`runAnalysisPhase`), especially on
- incremental builds. This can be a sign of a poor rule implementation, for
- example one that flattens depsets. Package loading can be slow by an
- excessive amount of targets, complex macros or recursive globs.
-* Individual slow actions, especially those on the critical path. It might be
- possible to split large actions into multiple smaller actions or reduce the
- set of (transitive) dependencies to speed them up. Also check for an unusual
- high non-`PROCESS_TIME` (such as `REMOTE_SETUP` or `FETCH`).
-* Bottlenecks, that is a small number of threads is busy while all others are
- idling / waiting for the result (see around 22s and 29s in Figure 1).
- Optimizing this will most likely require touching the rule implementations
- or Bazel itself to introduce more parallelism. This can also happen when
- there is an unusual amount of GC.
-
-## Profile file format
-
-The top-level object contains metadata (`otherData`) and the actual tracing data
-(`traceEvents`). The metadata contains extra info, for example the invocation ID
-and date of the Bazel invocation.
-
-Example:
-
-```json
-{
- "otherData": {
- "build_id": "101bff9a-7243-4c1a-8503-9dc6ae4c3b05",
- "date": "Wed Oct 26 08:22:35 CEST 2022",
- "profile_finish_ts": "1677666095162000",
- "output_base": "/usr/local/google/_bazel_johndoe/573d4be77eaa72b91a3dfaa497bf8cd0"
- },
- "traceEvents": [
- {"name":"thread_name","ph":"M","pid":1,"tid":0,"args":{"name":"Critical Path"}},
- ...
- {"cat":"build phase marker","name":"Launch Blaze","ph":"X","ts":-1306000,"dur":1306000,"pid":1,"tid":21},
- ...
- {"cat":"package creation","name":"foo","ph":"X","ts":2685358,"dur":784,"pid":1,"tid":246},
- ...
- {"name":"thread_name","ph":"M","pid":1,"tid":11,"args":{"name":"Garbage Collector"}},
- {"cat":"gc notification","name":"minor GC","ph":"X","ts":825986,"dur":11000,"pid":1,"tid":11},
- ...
- {"cat":"action processing","name":"Compiling foo/bar.c","ph":"X","ts":54413389,"dur":357594,"pid":1,"args":{"mnemonic":"CppCompile"},"tid":341},
- ]
-}
-```
-
-Timestamps (`ts`) and durations (`dur`) in the trace events are given in
-microseconds. The category (`cat`) is one of enum values of `ProfilerTask`.
-Note that some events are merged together if they are very short and close to
-each other; pass
-[`--noslim_profile`](/reference/command-line-reference#flag--slim_profile)
-if you would like to prevent event merging.
-
-See also the
-[Chrome Trace Event Format Specification](https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview).
diff --git a/8.0.1/advanced/performance/memory.mdx b/8.0.1/advanced/performance/memory.mdx
deleted file mode 100644
index 844e691..0000000
--- a/8.0.1/advanced/performance/memory.mdx
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: 'Optimize Memory'
----
-
-
-
-This page describes how to limit and reduce the memory Bazel uses.
-
-## Running Bazel with Limited RAM
-
-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#host-jvm-args),
-like `--host_jvm_args=-Xmx2g`.
-
-### Trade incremental build speeds for memory
-
-If your builds are too big, 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#discard-analysis-cache),
-[`--nokeep_state_after_build`](/reference/command-line-reference#flag--keep_state_after_build),
-and
-[`--notrack_incremental_state`](/reference/command-line-reference#flag--track_incremental_state).
-
-These flags will minimize the memory that Bazel uses in a build, at the cost of
-making future builds slower than a standard incremental build would be.
-
-You can also pass any one of these flags individually:
-
- * `--discard_analysis_cache` will reduce the memory used during execution (not
-analysis). Incremental builds will not have to redo package loading, but will
-have to redo analysis and execution (although the on-disk action cache can
-prevent most re-execution).
- * `--notrack_incremental_state` will not store any edges in Bazel's internal
- dependency graph, so that it is unusable for incremental builds. The next build
- will discard that data, but it is preserved until then, for internal debugging,
- unless `--nokeep_state_after_build` is specified.
- * `--nokeep_state_after_build` will discard all data after the build, so that
- incremental builds have to build from scratch (except for the on-disk action
- cache). Alone, it does not affect the high-water mark of the current build.
-
-### Trade build flexibility for memory with Skyfocus (Experimental)
-
-If you want to make Bazel use less memory *and* retain incremental build speeds,
-you can tell Bazel the working set of files that you will be modifying, and
-Bazel will only keep state needed to correctly incrementally rebuild changes to
-those files. This feature is called **Skyfocus**.
-
-To use Skyfocus, pass the `--experimental_enable_skyfocus` flag:
-
-```sh
-bazel build //pkg:target --experimental_enable_skyfocus
-```
-
-By default, the working set will be the set of files next to the target being
-built. In the example, all files in `//pkg` will be kept in the working set, and
-changes to files outside of the working set will be disallowed, until you issue
-`bazel clean` or restart the Bazel server.
-
-If you want to specify an exact set of files or directories, use the
-`--experimental_working_set` flag, like so:
-
-```sh
-bazel build //pkg:target --experimental_enable_skyfocus
---experimental_working_set=path/to/another/dir,path/to/tests/dir
-```
-
-You can also pass `--experimental_skyfocus_dump_post_gc_stats` to show the
-memory reduction amount:
-
-Putting it altogether, you should see something like this:
-
-```none
-$ bazel test //pkg:target //tests/... --experimental_enable_skyfocus --experimental_working_set dir1,dir2,dir3/subdir --experimental_skyfocus_dump_post_gc_stats
-INFO: --experimental_enable_skyfocus is enabled. Blaze will reclaim memory not needed to build the working set. Run 'blaze dump --skyframe=working_set' to show the working set, after this command.
-WARNING: Changes outside of the working set will cause a build error.
-INFO: Analyzed 149 targets (4533 packages loaded, 169438 targets configured).
-INFO: Found 25 targets and 124 test targets...
-INFO: Updated working set successfully.
-INFO: Focusing on 334 roots, 3 leafs... (use --experimental_skyfocus_dump_keys to show them)
-INFO: Heap: 1237MB -> 676MB (-45.31%)
-INFO: Elapsed time: 192.670s ...
-INFO: Build completed successfully, 62303 total actions
-```
-
-For this example, using Skyfocus allowed Bazel to drop 561MB (45%) of memory,
-and incremental builds to handle changes to files under `dir1`, `dir2`, and
-`dir3/subdir` will retain their fast speeds, with the tradeoff that Bazel cannot
-rebuild changed files outside of these directories.
-
-## Memory Profiling
-
-Bazel comes with a built-in memory profiler that can help you check your rule’s
-memory use. Read more about this process on the
-[Memory Profiling section](/rules/performance#memory-profiling) of our
-documentation on how to improve the performance of custom rules.
diff --git a/8.0.1/basics/artifact-based-builds.mdx b/8.0.1/basics/artifact-based-builds.mdx
deleted file mode 100644
index 79f3514..0000000
--- a/8.0.1/basics/artifact-based-builds.mdx
+++ /dev/null
@@ -1,279 +0,0 @@
----
-title: 'Artifact-Based Build Systems'
----
-
-
-
-This page covers artifact-based build systems and the philosophy behind their
-creation. Bazel is an artifact-based build system. While task-based build
-systems are good step above build scripts, they give too much power to
-individual engineers by letting them define their own tasks.
-
-Artifact-based build systems have a small number of tasks defined by the system
-that engineers can configure in a limited way. Engineers still tell the system
-**what** to build, but the build system determines **how** to build it. As with
-task-based build systems, artifact-based build systems, such as Bazel, still
-have buildfiles, but the contents of those buildfiles are very different. Rather
-than being an imperative set of commands in a Turing-complete scripting language
-describing how to produce an output, buildfiles in Bazel are a declarative
-manifest describing a set of artifacts to build, their dependencies, and a
-limited set of options that affect how they’re built. When engineers run `bazel`
-on the command line, they specify a set of targets to build (the **what**), and
-Bazel is responsible for configuring, running, and scheduling the compilation
-steps (the **how**). Because the build system now has full control over what
-tools to run when, it can make much stronger guarantees that allow it to be far
-more efficient while still guaranteeing correctness.
-
-## A functional perspective
-
-It’s easy to make an analogy between artifact-based build systems and functional
-programming. Traditional imperative programming languages (such as, Java, C, and
-Python) specify lists of statements to be executed one after another, in the
-same way that task-based build systems let programmers define a series of steps
-to execute. Functional programming languages (such as, Haskell and ML), in
-contrast, are structured more like a series of mathematical equations. In
-functional languages, the programmer describes a computation to perform, but
-leaves the details of when and exactly how that computation is executed to the
-compiler.
-
-This maps to the idea of declaring a manifest in an artifact-based build system
-and letting the system figure out how to execute the build. Many problems can't
-be easily expressed using functional programming, but the ones that do benefit
-greatly from it: the language is often able to trivially parallelize such
-programs and make strong guarantees about their correctness that would be
-impossible in an imperative language. The easiest problems to express using
-functional programming are the ones that simply involve transforming one piece
-of data into another using a series of rules or functions. And that’s exactly
-what a build system is: the whole system is effectively a mathematical function
-that takes source files (and tools like the compiler) as inputs and produces
-binaries as outputs. So, it’s not surprising that it works well to base a build
-system around the tenets of functional programming.
-
-## Understanding artifact-based build systems
-
-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:
-
-```python
-java_binary(
- name = "MyBinary",
- srcs = ["MyBinary.java"],
- deps = [
- ":mylib",
- ],
-)
-java_library(
- name = "mylib",
- srcs = ["MyLibrary.java", "MyHelper.java"],
- visibility = ["//java/com/example/myproduct:__subpackages__"],
- deps = [
- "//java/com/example/common",
- "//java/com/example/myproduct/otherlib",
- ],
-)
-```
-
-In Bazel, `BUILD` files define targets—the two types of targets here are
-`java_binary` and `java_library`. Every target corresponds to an artifact that
-can be created by the system: binary targets produce binaries that can be
-executed directly, and library targets produce libraries that can be used by
-binaries or other libraries. Every target has:
-
-* `name`: how the target is referenced on the command line and by other
- targets
-* `srcs`: the source files to compiled to create the artifact for the target
-* `deps`: other targets that must be built before this target and linked into
- it
-
-Dependencies can either be within the same package (such as `MyBinary`’s
-dependency on `:mylib`) or on a different package in the same source hierarchy
-(such as `mylib`’s dependency on `//java/com/example/common`).
-
-As with task-based build systems, you perform builds using Bazel’s command-line
-tool. To build the `MyBinary` target, you run `bazel build :MyBinary`. After
-entering that command for the first time in a clean repository, Bazel:
-
-1. Parses every `BUILD` file in the workspace to create a graph of dependencies
- among artifacts.
-1. Uses the graph to determine the transitive dependencies of `MyBinary`; that
- is, every target that `MyBinary` depends on and every target that those
- targets depend on, recursively.
-1. Builds each of those dependencies, in order. Bazel starts by building each
- target that has no other dependencies and keeps track of which dependencies
- still need to be built for each target. As soon as all of a target’s
- dependencies are built, Bazel starts building that target. This process
- continues until every one of `MyBinary`’s transitive dependencies have been
- built.
-1. Builds `MyBinary` to produce a final executable binary that links in all of
- the dependencies that were built in step 3.
-
-Fundamentally, it might not seem like what’s happening here is that much
-different than what happened when using a task-based build system. Indeed, the
-end result is the same binary, and the process for producing it involved
-analyzing a bunch of steps to find dependencies among them, and then running
-those steps in order. But there are critical differences. The first one appears
-in step 3: because Bazel knows that each target only produces a Java library, it
-knows that all it has to do is run the Java compiler rather than an arbitrary
-user-defined script, so it knows that it’s safe to run these steps in parallel.
-This can produce an order of magnitude performance improvement over building
-targets one at a time on a multicore machine, and is only possible because the
-artifact-based approach leaves the build system in charge of its own execution
-strategy so that it can make stronger guarantees about parallelism.
-
-The benefits extend beyond parallelism, though. The next thing that this
-approach gives us becomes apparent when the developer types `bazel
-build :MyBinary` a second time without making any changes: Bazel exits in less
-than a second with a message saying that the target is up to date. This is
-possible due to the functional programming paradigm we talked about
-earlier—Bazel knows that each target is the result only of running a Java
-compiler, and it knows that the output from the Java compiler depends only on
-its inputs, so as long as the inputs haven’t changed, the output can be reused.
-And this analysis works at every level; if `MyBinary.java` changes, Bazel knows
-to rebuild `MyBinary` but reuse `mylib`. If a source file for
-`//java/com/example/common` changes, Bazel knows to rebuild that library,
-`mylib`, and `MyBinary`, but reuse `//java/com/example/myproduct/otherlib`.
-Because Bazel knows about the properties of the tools it runs at every step,
-it’s able to rebuild only the minimum set of artifacts each time while
-guaranteeing that it won’t produce stale builds.
-
-Reframing the build process in terms of artifacts rather than tasks is subtle
-but powerful. By reducing the flexibility exposed to the programmer, the build
-system can know more about what is being done at every step of the build. It can
-use this knowledge to make the build far more efficient by parallelizing build
-processes and reusing their outputs. But this is really just the first step, and
-these building blocks of parallelism and reuse form the basis for a distributed
-and highly scalable build system.
-
-## Other nifty Bazel tricks
-
-Artifact-based build systems fundamentally solve the problems with parallelism
-and reuse that are inherent in task-based build systems. But there are still a
-few problems that came up earlier that we haven’t addressed. Bazel has clever
-ways of solving each of these, and we should discuss them before moving on.
-
-### Tools as dependencies
-
-One problem we ran into earlier was that builds depended on the tools installed
-on our machine, and reproducing builds across systems could be difficult due to
-different tool versions or locations. The problem becomes even more difficult
-when your project uses languages that require different tools based on which
-platform they’re being built on or compiled for (such as, Windows versus Linux),
-and each of those platforms requires a slightly different set of tools to do the
-same job.
-
-Bazel solves the first part of this problem by treating tools as dependencies to
-each target. Every `java_library` in the workspace implicitly depends on a Java
-compiler, which defaults to a well-known compiler. Whenever Bazel builds a
-`java_library`, it checks to make sure that the specified compiler is available
-at a known location. Just like any other dependency, if the Java compiler
-changes, every artifact that depends on it is rebuilt.
-
-Bazel solves the second part of the problem, platform independence, by setting
-[build configurations](/run/build#build-config-cross-compilation). Rather than
-targets depending directly on their tools, they depend on types of configurations:
-
-* **Host configuration**: building tools that run during the build
-* **Target configuration**: building the binary you ultimately requested
-
-### Extending the build system
-
-Bazel comes with targets for several popular programming languages out of the
-box, but engineers will always want to do more—part of the benefit of task-based
-systems is their flexibility in supporting any kind of build process, and it
-would be better not to give that up in an artifact-based build system.
-Fortunately, Bazel allows its supported target types to be extended by
-[adding custom rules](/extending/rules).
-
-To define a rule in Bazel, the rule author declares the inputs that the rule
-requires (in the form of attributes passed in the `BUILD` file) and the fixed
-set of outputs that the rule produces. The author also defines the actions that
-will be generated by that rule. Each action declares its inputs and outputs,
-runs a particular executable or writes a particular string to a file, and can be
-connected to other actions via its inputs and outputs. This means that actions
-are the lowest-level composable unit in the build system—an action can do
-whatever it wants so long as it uses only its declared inputs and outputs, and
-Bazel takes care of scheduling actions and caching their results as appropriate.
-
-The system isn’t foolproof given that there’s no way to stop an action developer
-from doing something like introducing a nondeterministic process as part of
-their action. But this doesn’t happen very often in practice, and pushing the
-possibilities for abuse all the way down to the action level greatly decreases
-opportunities for errors. Rules supporting many common languages and tools are
-widely available online, and most projects will never need to define their own
-rules. Even for those that do, rule definitions only need to be defined in one
-central place in the repository, meaning most engineers will be able to use
-those rules without ever having to worry about their implementation.
-
-### Isolating the environment
-
-Actions sound like they might run into the same problems as tasks in other
-systems—isn’t it still possible to write actions that both write to the same
-file and end up conflicting with one another? Actually, Bazel makes these
-conflicts impossible by using _[sandboxing](/docs/sandboxing)_. On supported
-systems, every action is isolated from every other action via a filesystem
-sandbox. Effectively, each action can see only a restricted view of the
-filesystem that includes the inputs it has declared and any outputs it has
-produced. This is enforced by systems such as LXC on Linux, the same technology
-behind Docker. This means that it’s impossible for actions to conflict with one
-another because they are unable to read any files they don’t declare, and any
-files that they write but don’t declare will be thrown away when the action
-finishes. Bazel also uses sandboxes to restrict actions from communicating via
-the network.
-
-### Making external dependencies deterministic
-
-There’s still one problem remaining: build systems often need to download
-dependencies (whether tools or libraries) from external sources rather than
-directly building them. This can be seen in the example via the
-`@com_google_common_guava_guava//jar` dependency, which downloads a `JAR` file
-from Maven.
-
-Depending on files outside of the current workspace is risky. Those files could
-change at any time, potentially requiring the build system to constantly check
-whether they’re fresh. If a remote file changes without a corresponding change
-in the workspace source code, it can also lead to unreproducible builds—a build
-might work one day and fail the next for no obvious reason due to an unnoticed
-dependency change. Finally, an external dependency can introduce a huge security
-risk when it is owned by a third party: if an attacker is able to infiltrate
-that third-party server, they can replace the dependency file with something of
-their own design, potentially giving them full control over your build
-environment and its output.
-
-The fundamental problem is that we want the build system to be aware of these
-files without having to check them into source control. Updating a dependency
-should be a conscious choice, but that choice should be made once in a central
-place rather than managed by individual engineers or automatically by the
-system. This is because even with a “Live at Head” model, we still want builds
-to be deterministic, which implies that if you check out a commit from last
-week, you should see your dependencies as they were then rather than as they are
-now.
-
-Bazel and some other build systems address this problem by requiring a
-workspacewide manifest file that lists a _cryptographic hash_ for every external
-dependency in the workspace. The hash is a concise way to uniquely represent the
-file without checking the entire file into source control. Whenever a new
-external dependency is referenced from a workspace, that dependency’s hash is
-added to the manifest, either manually or automatically. When Bazel runs a
-build, it checks the actual hash of its cached dependency against the expected
-hash defined in the manifest and redownloads the file only if the hash differs.
-
-If the artifact we download has a different hash than the one declared in the
-manifest, the build will fail unless the hash in the manifest is updated. This
-can be done automatically, but that change must be approved and checked into
-source control before the build will accept the new dependency. This means that
-there’s always a record of when a dependency was updated, and an external
-dependency can’t change without a corresponding change in the workspace source.
-It also means that, when checking out an older version of the source code, the
-build is guaranteed to use the same dependencies that it was using at the point
-when that version was checked in (or else it will fail if those dependencies are
-no longer available).
-
-Of course, it can still be a problem if a remote server becomes unavailable or
-starts serving corrupt data—this can cause all of your builds to begin failing
-if you don’t have another copy of that dependency available. To avoid this
-problem, we recommend that, for any nontrivial project, you mirror all of its
-dependencies onto servers or services that you trust and control. Otherwise you
-will always be at the mercy of a third party for your build system’s
-availability, even if the checked-in hashes guarantee its security.
diff --git a/8.0.1/basics/build-systems.mdx b/8.0.1/basics/build-systems.mdx
deleted file mode 100644
index b3c6338..0000000
--- a/8.0.1/basics/build-systems.mdx
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: 'Why a Build System?'
----
-
-
-
-This page discusses what build systems are, what they do, why you should use a
-build system, and why compilers and build scripts aren't the best choice as your
-organization starts to scale. It's intended for developers who don't have much
-experience with a build system.
-
-## What is a build system?
-
-Fundamentally, all build systems have a straightforward purpose: they transform
-the source code written by engineers into executable binaries that can be read
-by machines. Build systems aren't just for human-authored code; they also allow
-machines to create builds automatically, whether for testing or for releases to
-production. In an organization with thousands of engineers, it's common that
-most builds are triggered automatically rather than directly by engineers.
-
-### Can't I just use a compiler?
-
-The need for a build system might not be immediately obvious. Most engineers
-don't use a build system while learning to code: most start by invoking tools
-like `gcc` or `javac` directly from the command line, or the equivalent in an
-integrated development environment (IDE). As long as all the source code is in
-the same directory, a command like this works fine:
-
-```posix-terminal
-javac *.java
-```
-
-This instructs the Java compiler to take every Java source file in the current
-directory and turn it into a binary class file. In the simplest case, this is
-all you need.
-
-However, as soon as code expands, the complications begin. `javac` is smart
-enough to look in subdirectories of the current directory to find code to
-import. But it has no way of finding code stored in _other parts_ of the
-filesystem (perhaps a library shared by several projects). It also only knows
-how to build Java code. Large systems often involve different pieces written in
-a variety of programming languages with webs of dependencies among those pieces,
-meaning no compiler for a single language can possibly build the entire system.
-
-Once you're dealing with code from multiple languages or multiple compilation
-units, building code is no longer a one-step process. Now you must evaluate what
-your code depends on and build those pieces in the proper order, possibly using
-a different set of tools for each piece. If any dependencies change, you must
-repeat this process to avoid depending on stale binaries. For a codebase of even
-moderate size, this process quickly becomes tedious and error-prone.
-
-The compiler also doesn’t know anything about how to handle external
-dependencies, such as third-party `JAR` files in Java. Without a build system,
-you could manage this by downloading the dependency from the internet, sticking
-it in a `lib` folder on the hard drive, and configuring the compiler to read
-libraries from that directory. Over time, it's difficult to maintain the
-updates, versions, and source of these external dependencies.
-
-### What about shell scripts?
-
-Suppose that your hobby project starts out simple enough that you can build it
-using just a compiler, but you begin running into some of the problems described
-previously. Maybe you still don’t think you need a build system and can automate
-away the tedious parts using some simple shell scripts that take care of
-building things in the correct order. This helps out for a while, but pretty
-soon you start running into even more problems:
-
-* It becomes tedious. As your system grows more complex, you begin spending
- almost as much time working on your build scripts as on real code. Debugging
- shell scripts is painful, with more and more hacks being layered on top of
- one another.
-
-* It’s slow. To make sure you weren’t accidentally relying on stale libraries,
- you have your build script build every dependency in order every time you
- run it. You think about adding some logic to detect which parts need to be
- rebuilt, but that sounds awfully complex and error prone for a script. Or
- you think about specifying which parts need to be rebuilt each time, but
- then you’re back to square one.
-
-* Good news: it’s time for a release! Better go figure out all the arguments
- you need to pass to the jar command to make your final build. And remember
- how to upload it and push it out to the central repository. And build and
- push the documentation updates, and send out a notification to users. Hmm,
- maybe this calls for another script...
-
-* Disaster! Your hard drive crashes, and now you need to recreate your entire
- system. You were smart enough to keep all of your source files in version
- control, but what about those libraries you downloaded? Can you find them
- all again and make sure they were the same version as when you first
- downloaded them? Your scripts probably depended on particular tools being
- installed in particular places—can you restore that same environment so that
- the scripts work again? What about all those environment variables you set a
- long time ago to get the compiler working just right and then forgot about?
-
-* Despite the problems, your project is successful enough that you’re able to
- begin hiring more engineers. Now you realize that it doesn’t take a disaster
- for the previous problems to arise—you need to go through the same painful
- bootstrapping process every time a new developer joins your team. And
- despite your best efforts, there are still small differences in each
- person’s system. Frequently, what works on one person’s machine doesn’t work
- on another’s, and each time it takes a few hours of debugging tool paths or
- library versions to figure out where the difference is.
-
-* You decide that you need to automate your build system. In theory, this is
- as simple as getting a new computer and setting it up to run your build
- script every night using cron. You still need to go through the painful
- setup process, but now you don’t have the benefit of a human brain being
- able to detect and resolve minor problems. Now, every morning when you get
- in, you see that last night’s build failed because yesterday a developer
- made a change that worked on their system but didn’t work on the automated
- build system. Each time it’s a simple fix, but it happens so often that you
- end up spending a lot of time each day discovering and applying these simple
- fixes.
-
-* Builds become slower and slower as the project grows. One day, while waiting
- for a build to complete, you gaze mournfully at the idle desktop of your
- coworker, who is on vacation, and wish there were a way to take advantage of
- all that wasted computational power.
-
-You’ve run into a classic problem of scale. For a single developer working on at
-most a couple hundred lines of code for at most a week or two (which might have
-been the entire experience thus far of a junior developer who just graduated
-university), a compiler is all you need. Scripts can maybe take you a little bit
-farther. But as soon as you need to coordinate across multiple developers and
-their machines, even a perfect build script isn’t enough because it becomes very
-difficult to account for the minor differences in those machines. At this point,
-this simple approach breaks down and it’s time to invest in a real build system.
diff --git a/8.0.1/basics/dependencies.mdx b/8.0.1/basics/dependencies.mdx
deleted file mode 100644
index 1d3bf8f..0000000
--- a/8.0.1/basics/dependencies.mdx
+++ /dev/null
@@ -1,301 +0,0 @@
----
-title: 'Dependency Management'
----
-
-
-
-In looking through the previous pages, one theme repeats over and over: managing
-your own code is fairly straightforward, but managing its dependencies is much
-more difficult. There are all sorts of dependencies: sometimes there’s a
-dependency on a task (such as “push the documentation before I mark a release as
-complete”), and sometimes there’s a dependency on an artifact (such as “I need
-to have the latest version of the computer vision library to build my code”).
-Sometimes, you have internal dependencies on another part of your codebase, and
-sometimes you have external dependencies on code or data owned by another team
-(either in your organization or a third party). But in any case, the idea of “I
-need that before I can have this” is something that recurs repeatedly in the
-design of build systems, and managing dependencies is perhaps the most
-fundamental job of a build system.
-
-## Dealing with Modules and Dependencies
-
-Projects that use artifact-based build systems like Bazel are broken into a set
-of modules, with modules expressing dependencies on one another via `BUILD`
-files. Proper organization of these modules and dependencies can have a huge
-effect on both the performance of the build system and how much work it takes to
-maintain.
-
-## Using Fine-Grained Modules and the 1:1:1 Rule
-
-The first question that comes up when structuring an artifact-based build is
-deciding how much functionality an individual module should encompass. In Bazel,
-a _module_ is represented by a target specifying a buildable unit like a
-`java_library` or a `go_binary`. At one extreme, the entire project could be
-contained in a single module by putting one `BUILD` file at the root and
-recursively globbing together all of that project’s source files. At the other
-extreme, nearly every source file could be made into its own module, effectively
-requiring each file to list in a `BUILD` file every other file it depends on.
-
-Most projects fall somewhere between these extremes, and the choice involves a
-trade-off between performance and maintainability. Using a single module for the
-entire project might mean that you never need to touch the `BUILD` file except
-when adding an external dependency, but it means that the build system must
-always build the entire project all at once. This means that it won’t be able to
-parallelize or distribute parts of the build, nor will it be able to cache parts
-that it’s already built. One-module-per-file is the opposite: the build system
-has the maximum flexibility in caching and scheduling steps of the build, but
-engineers need to expend more effort maintaining lists of dependencies whenever
-they change which files reference which.
-
-Though the exact granularity varies by language (and often even within
-language), Google tends to favor significantly smaller modules than one might
-typically write in a task-based build system. A typical production binary at
-Google often depends on tens of thousands of targets, and even a moderate-sized
-team can own several hundred targets within its codebase. For languages like
-Java that have a strong built-in notion of packaging, each directory usually
-contains a single package, target, and `BUILD` file (Pants, another build system
-based on Bazel, calls this the 1:1:1 rule). Languages with weaker packaging
-conventions frequently define multiple targets per `BUILD` file.
-
-The benefits of smaller build targets really begin to show at scale because they
-lead to faster distributed builds and a less frequent need to rebuild targets.
-The advantages become even more compelling after testing enters the picture, as
-finer-grained targets mean that the build system can be much smarter about
-running only a limited subset of tests that could be affected by any given
-change. Because Google believes in the systemic benefits of using smaller
-targets, we’ve made some strides in mitigating the downside by investing in
-tooling to automatically manage `BUILD` files to avoid burdening developers.
-
-Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
-
-## Minimizing Module Visibility
-
-Bazel and other build systems allow each target to specify a visibility — a
-property that determines which other targets may depend on it. A private target
-can only be referenced within its own `BUILD` file. A target may grant broader
-visibility to the targets of an explicitly defined list of `BUILD` files, or, in
-the case of public visibility, to every target in the workspace.
-
-As with most programming languages, it is usually best to minimize visibility as
-much as possible. Generally, teams at Google will make targets public only if
-those targets represent widely used libraries available to any team at Google.
-Teams that require others to coordinate with them before using their code will
-maintain an allowlist of customer targets as their target’s visibility. Each
-team’s internal implementation targets will be restricted to only directories
-owned by the team, and most `BUILD` files will have only one target that isn’t
-private.
-
-## Managing Dependencies
-
-Modules need to be able to refer to one another. The downside of breaking a
-codebase into fine-grained modules is that you need to manage the dependencies
-among those modules (though tools can help automate this). Expressing these
-dependencies usually ends up being the bulk of the content in a `BUILD` file.
-
-### Internal dependencies
-
-In a large project broken into fine-grained modules, most dependencies are
-likely to be internal; that is, on another target defined and built in the same
-source repository. Internal dependencies differ from external dependencies in
-that they are built from source rather than downloaded as a prebuilt artifact
-while running the build. This also means that there’s no notion of “version” for
-internal dependencies—a target and all of its internal dependencies are always
-built at the same commit/revision in the repository. One issue that should be
-handled carefully with regard to internal dependencies is how to treat
-transitive dependencies (Figure 1). Suppose target A depends on target B, which
-depends on a common library target C. Should target A be able to use classes
-defined in target C?
-
-[](/images/transitive-dependencies.png)
-
-**Figure 1**. Transitive dependencies
-
-As far as the underlying tools are concerned, there’s no problem with this; both
-B and C will be linked into target A when it is built, so any symbols defined in
-C are known to A. Bazel allowed this for many years, but as Google grew, we
-began to see problems. Suppose that B was refactored such that it no longer
-needed to depend on C. If B’s dependency on C was then removed, A and any other
-target that used C via a dependency on B would break. Effectively, a target’s
-dependencies became part of its public contract and could never be safely
-changed. This meant that dependencies accumulated over time and builds at Google
-started to slow down.
-
-Google eventually solved this issue by introducing a “strict transitive
-dependency mode” in Bazel. In this mode, Bazel detects whether a target tries to
-reference a symbol without depending on it directly and, if so, fails with an
-error and a shell command that can be used to automatically insert the
-dependency. Rolling this change out across Google’s entire codebase and
-refactoring every one of our millions of build targets to explicitly list their
-dependencies was a multiyear effort, but it was well worth it. Our builds are
-now much faster given that targets have fewer unnecessary dependencies, and
-engineers are empowered to remove dependencies they don’t need without worrying
-about breaking targets that depend on them.
-
-As usual, enforcing strict transitive dependencies involved a trade-off. It made
-build files more verbose, as frequently used libraries now need to be listed
-explicitly in many places rather than pulled in incidentally, and engineers
-needed to spend more effort adding dependencies to `BUILD` files. We’ve since
-developed tools that reduce this toil by automatically detecting many missing
-dependencies and adding them to a `BUILD` files without any developer
-intervention. But even without such tools, we’ve found the trade-off to be well
-worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
-is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
-on Java code by default.
-
-### External dependencies
-
-If a dependency isn’t internal, it must be external. External dependencies are
-those on artifacts that are built and stored outside of the build system. The
-dependency is imported directly from an artifact repository (typically accessed
-over the internet) and used as-is rather than being built from source. One of
-the biggest differences between external and internal dependencies is that
-external dependencies have versions, and those versions exist independently of
-the project’s source code.
-
-### Automatic versus manual dependency management
-
-Build systems can allow the versions of external dependencies to be managed
-either manually or automatically. When managed manually, the buildfile
-explicitly lists the version it wants to download from the artifact repository,
-often using a [semantic version string](https://semver.org/) such
-as `1.1.4`. When managed automatically, the source file specifies a range of
-acceptable versions, and the build system always downloads the latest one. For
-example, Gradle allows a dependency version to be declared as “1.+” to specify
-that any minor or patch version of a dependency is acceptable so long as the
-major version is 1.
-
-Automatically managed dependencies can be convenient for small projects, but
-they’re usually a recipe for disaster on projects of nontrivial size or that are
-being worked on by more than one engineer. The problem with automatically
-managed dependencies is that you have no control over when the version is
-updated. There’s no way to guarantee that external parties won’t make breaking
-updates (even when they claim to use semantic versioning), so a build that
-worked one day might be broken the next with no easy way to detect what changed
-or to roll it back to a working state. Even if the build doesn’t break, there
-can be subtle behavior or performance changes that are impossible to track down.
-
-In contrast, because manually managed dependencies require a change in source
-control, they can be easily discovered and rolled back, and it’s possible to
-check out an older version of the repository to build with older dependencies.
-Bazel requires that versions of all dependencies be specified manually. At even
-moderate scales, the overhead of manual version management is well worth it for
-the stability it provides.
-
-### The One-Version Rule
-
-Different versions of a library are usually represented by different artifacts,
-so in theory there’s no reason that different versions of the same external
-dependency couldn’t both be declared in the build system under different names.
-That way, each target could choose which version of the dependency it wanted to
-use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
-all third-party dependencies in our codebase.
-
-The biggest problem with allowing multiple versions is the diamond dependency
-issue. Suppose that target A depends on target B and on v1 of an external
-library. If target B is later refactored to add a dependency on v2 of the same
-external library, target A will break because it now depends implicitly on two
-different versions of the same library. Effectively, it’s never safe to add a
-new dependency from a target to any third-party library with multiple versions,
-because any of that target’s users could already be depending on a different
-version. Following the One-Version Rule makes this conflict impossible—if a
-target adds a dependency on a third-party library, any existing dependencies
-will already be on that same version, so they can happily coexist.
-
-### Transitive external dependencies
-
-Dealing with the transitive dependencies of an external dependency can be
-particularly difficult. Many artifact repositories such as Maven Central, allow
-artifacts to specify dependencies on particular versions of other artifacts in
-the repository. Build tools like Maven or Gradle often recursively download each
-transitive dependency by default, meaning that adding a single dependency in
-your project could potentially cause dozens of artifacts to be downloaded in
-total.
-
-This is very convenient: when adding a dependency on a new library, it would be
-a big pain to have to track down each of that library’s transitive dependencies
-and add them all manually. But there’s also a huge downside: because different
-libraries can depend on different versions of the same third-party library, this
-strategy necessarily violates the One-Version Rule and leads to the diamond
-dependency problem. If your target depends on two external libraries that use
-different versions of the same dependency, there’s no telling which one you’ll
-get. This also means that updating an external dependency could cause seemingly
-unrelated failures throughout the codebase if the new version begins pulling in
-conflicting versions of some of its dependencies.
-
-Bazel did not use to automatically download transitive dependencies. It used to
-employ a `WORKSPACE` file that required all transitive dependencies to be
-listed, which led to a lot of pain when managing external dependencies. Bazel
-has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/external/overview) for more details.
-
-Yet again, the choice here is one between convenience and scalability. Small
-projects might prefer not having to worry about managing transitive dependencies
-themselves and might be able to get away with using automatic transitive
-dependencies. This strategy becomes less and less appealing as the organization
-and codebase grows, and conflicts and unexpected results become more and more
-frequent. At larger scales, the cost of manually managing dependencies is much
-less than the cost of dealing with issues caused by automatic dependency
-management.
-
-### Caching build results using external dependencies
-
-External dependencies are most often provided by third parties that release
-stable versions of libraries, perhaps without providing source code. Some
-organizations might also choose to make some of their own code available as
-artifacts, allowing other pieces of code to depend on them as third-party rather
-than internal dependencies. This can theoretically speed up builds if artifacts
-are slow to build but quick to download.
-
-However, this also introduces a lot of overhead and complexity: someone needs to
-be responsible for building each of those artifacts and uploading them to the
-artifact repository, and clients need to ensure that they stay up to date with
-the latest version. Debugging also becomes much more difficult because different
-parts of the system will have been built from different points in the
-repository, and there is no longer a consistent view of the source tree.
-
-A better way to solve the problem of artifacts taking a long time to build is to
-use a build system that supports remote caching, as described earlier. Such a
-build system saves the resulting artifacts from every build to a location that
-is shared across engineers, so if a developer depends on an artifact that was
-recently built by someone else, the build system automatically downloads it
-instead of building it. This provides all of the performance benefits of
-depending directly on artifacts while still ensuring that builds are as
-consistent as if they were always built from the same source. This is the
-strategy used internally by Google, and Bazel can be configured to use a remote
-cache.
-
-### Security and reliability of external dependencies
-
-Depending on artifacts from third-party sources is inherently risky. There’s an
-availability risk if the third-party source (such as an artifact repository)
-goes down, because your entire build might grind to a halt if it’s unable to
-download an external dependency. There’s also a security risk: if the
-third-party system is compromised by an attacker, the attacker could replace the
-referenced artifact with one of their own design, allowing them to inject
-arbitrary code into your build. Both problems can be mitigated by mirroring any
-artifacts you depend on onto servers you control and blocking your build system
-from accessing third-party artifact repositories like Maven Central. The
-trade-off is that these mirrors take effort and resources to maintain, so the
-choice of whether to use them often depends on the scale of the project. The
-security issue can also be completely prevented with little overhead by
-requiring the hash of each third-party artifact to be specified in the source
-repository, causing the build to fail if the artifact is tampered with. Another
-alternative that completely sidesteps the issue is to vendor your project’s
-dependencies. When a project vendors its dependencies, it checks them into
-source control alongside the project’s source code, either as source or as
-binaries. This effectively means that all of the project’s external dependencies
-are converted to internal dependencies. Google uses this approach internally,
-checking every third-party library referenced throughout Google into a
-`third_party` directory at the root of Google’s source tree. However, this works
-at Google only because Google’s source control system is custom built to handle
-an extremely large monorepo, so vendoring might not be an option for all
-organizations.
diff --git a/8.0.1/basics/distributed-builds.mdx b/8.0.1/basics/distributed-builds.mdx
deleted file mode 100644
index c32f44f..0000000
--- a/8.0.1/basics/distributed-builds.mdx
+++ /dev/null
@@ -1,137 +0,0 @@
----
-title: 'Distributed Builds'
----
-
-
-
-When you have a large codebase, chains of dependencies can become very deep.
-Even simple binaries can often depend on tens of thousands of build targets. At
-this scale, it’s simply impossible to complete a build in a reasonable amount
-of time on a single machine: no build system can get around the fundamental
-laws of physics imposed on a machine’s hardware. The only way to make this work
-is with a build system that supports distributed builds wherein the units of
-work being done by the system are spread across an arbitrary and scalable
-number of machines. Assuming we’ve broken the system’s work into small enough
-units (more on this later), this would allow us to complete any build of any
-size as quickly as we’re willing to pay for. This scalability is the holy grail
-we’ve been working toward by defining an artifact-based build system.
-
-## Remote caching
-
-The simplest type of distributed build is one that only leverages _remote
-caching_, which is shown in Figure 1.
-
-[](/images/distributed-build-remote-cache.png)
-
-**Figure 1**. A distributed build showing remote caching
-
-Every system that performs builds, including both developer workstations and
-continuous integration systems, shares a reference to a common remote cache
-service. This service might be a fast and local short-term storage system like
-Redis or a cloud service like Google Cloud Storage. Whenever a user needs to
-build an artifact, whether directly or as a dependency, the system first checks
-with the remote cache to see if that artifact already exists there. If so, it
-can download the artifact instead of building it. If not, the system builds the
-artifact itself and uploads the result back to the cache. This means that
-low-level dependencies that don’t change very often can be built once and shared
-across users rather than having to be rebuilt by each user. At Google, many
-artifacts are served from a cache rather than built from scratch, vastly
-reducing the cost of running our build system.
-
-For a remote caching system to work, the build system must guarantee that builds
-are completely reproducible. That is, for any build target, it must be possible
-to determine the set of inputs to that target such that the same set of inputs
-will produce exactly the same output on any machine. This is the only way to
-ensure that the results of downloading an artifact are the same as the results
-of building it oneself. Note that this requires that each artifact in the cache
-be keyed on both its target and a hash of its inputs—that way, different
-engineers could make different modifications to the same target at the same
-time, and the remote cache would store all of the resulting artifacts and serve
-them appropriately without conflict.
-
-Of course, for there to be any benefit from a remote cache, downloading an
-artifact needs to be faster than building it. This is not always the case,
-especially if the cache server is far from the machine doing the build. Google’s
-network and build system is carefully tuned to be able to quickly share build
-results.
-
-## Remote execution
-
-Remote caching isn’t a true distributed build. If the cache is lost or if you
-make a low-level change that requires everything to be rebuilt, you still need
-to perform the entire build locally on your machine. The true goal is to support
-remote execution, in which the actual work of doing the build can be spread
-across any number of workers. Figure 2 depicts a remote execution system.
-
-[](/images/remote-execution-system.png)
-
-**Figure 2**. A remote execution system
-
-The build tool running on each user’s machine (where users are either human
-engineers or automated build systems) sends requests to a central build master.
-The build master breaks the requests into their component actions and schedules
-the execution of those actions over a scalable pool of workers. Each worker
-performs the actions asked of it with the inputs specified by the user and
-writes out the resulting artifacts. These artifacts are shared across the other
-machines executing actions that require them until the final output can be
-produced and sent to the user.
-
-The trickiest part of implementing such a system is managing the communication
-between the workers, the master, and the user’s local machine. Workers might
-depend on intermediate artifacts produced by other workers, and the final output
-needs to be sent back to the user’s local machine. To do this, we can build on
-top of the distributed cache described previously by having each worker write
-its results to and read its dependencies from the cache. The master blocks
-workers from proceeding until everything they depend on has finished, in which
-case they’ll be able to read their inputs from the cache. The final product is
-also cached, allowing the local machine to download it. Note that we also need a
-separate means of exporting the local changes in the user’s source tree so that
-workers can apply those changes before building.
-
-For this to work, all of the parts of the artifact-based build systems described
-earlier need to come together. Build environments must be completely
-self-describing so that we can spin up workers without human intervention. Build
-processes themselves must be completely self-contained because each step might
-be executed on a different machine. Outputs must be completely deterministic so
-that each worker can trust the results it receives from other workers. Such
-guarantees are extremely difficult for a task-based system to provide, which
-makes it nigh-impossible to build a reliable remote execution system on top of
-one.
-
-## Distributed builds at Google
-
-Since 2008, Google has been using a distributed build system that employs both
-remote caching and remote execution, which is illustrated in Figure 3.
-
-[](/images/high-level-build-system.png)
-
-**Figure 3**. Google’s distributed build system
-
-Google’s remote cache is called ObjFS. It consists of a backend that stores
-build outputs in Bigtables distributed throughout our fleet of production
-machines and a frontend FUSE daemon named objfsd that runs on each developer’s
-machine. The FUSE daemon allows engineers to browse build outputs as if they
-were normal files stored on the workstation, but with the file content
-downloaded on-demand only for the few files that are directly requested by the
-user. Serving file contents on-demand greatly reduces both network and disk
-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 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
-been created by any other user of the system. If not, it places the action into
-a queue. A large pool of Executor jobs continually read actions from this queue,
-execute them, and store the results directly in the ObjFS Bigtables. These
-results are available to the executors for future actions, or to be downloaded
-by the end user via objfsd.
-
-The end result is a system that scales to efficiently support all builds
-performed at Google. And the scale of Google’s builds is truly massive: Google
-runs millions of builds executing millions of test cases and producing petabytes
-of build outputs from billions of lines of source code every day. Not only does
-such a system let our engineers build complex codebases quickly, it also allows
-us to implement a huge number of automated tools and systems that rely on our
-build.
diff --git a/8.0.1/basics/hermeticity.mdx b/8.0.1/basics/hermeticity.mdx
deleted file mode 100644
index 282aad8..0000000
--- a/8.0.1/basics/hermeticity.mdx
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: 'Hermeticity'
----
-
-
-
-This page covers hermeticity, the benefits of using hermetic builds, and
-strategies for identifying non-hermetic behavior in your builds.
-
-## Overview
-
-When given the same input source code and product configuration, a hermetic
-build system always returns the same output by isolating the build from changes
-to the host system.
-
-In order to isolate the build, hermetic builds are insensitive to libraries and
-other software installed on the local or remote host machine. They depend on
-specific versions of build tools, such as compilers, and dependencies, such as
-libraries. This makes the build process self-contained as it doesn't rely on
-services external to the build environment.
-
-The two important aspects of hermeticity are:
-
-* **Isolation**: Hermetic build systems treat tools as source code. They
- download copies of tools and manage their storage and use inside managed file
- trees. This creates isolation between the host machine and local user,
- including installed versions of languages.
-* **Source identity**: Hermetic build systems try to ensure the sameness of
- inputs. Code repositories, such as Git, identify sets of code mutations with a
- unique hash code. Hermetic build systems use this hash to identify changes to
- the build's input.
-
-## Benefits
-
-The major benefits of hermetic builds are:
-
-* **Speed**: The output of an action can be cached, and the action need not be
- run again unless inputs change.
-* **Parallel execution**: For given input and output, the build system can
- construct a graph of all actions to calculate efficient and parallel
- execution. The build system loads the rules and calculates an action graph
- and hash inputs to look up in the cache.
-* **Multiple builds**: You can build multiple hermetic builds on the same
- machine, each build using different tools and versions.
-* **Reproducibility**: Hermetic builds are good for troubleshooting because you
- know the exact conditions that produced the build.
-
-## Identifying non-hermeticity
-
-If you are preparing to switch to Bazel, migration is easier if you improve
-your existing builds' hermeticity in advance. Some common sources of
-non-hermeticity in builds are:
-
-* Arbitrary processing in `.mk` files
-* Actions or tooling that create files non-deterministically, usually involving
- build IDs or timestamps
-* System binaries that differ across hosts (such as `/usr/bin` binaries, absolute
- paths, system C++ compilers for native C++ rules autoconfiguration)
-* Writing to the source tree during the build. This prevents the same source
- tree from being used for another target. The first build writes to the source
- tree, fixing the source tree for target A. Then trying to build target B may
- fail.
-
-## Troubleshooting non-hermetic builds
-
-Starting with local execution, issues that affect local cache hits reveal
-non-hermetic actions.
-
-* Ensure null sequential builds: If you run `make` and get a successful build,
- running the build again should not rebuild any targets. If you run each build
- step twice or on different systems, compare a hash of the file contents and
- get results that differ, the build is not reproducible.
-* Run steps to
- [debug local cache hits](/remote/cache-remote#troubleshooting-cache-hits)
- from a variety of potential client machines to ensure that you catch any
- cases of client environment leaking into the actions.
-* Execute a build within a docker container that contains nothing but the
- checked-out source tree and explicit list of host tools. Build breakages and
- error messages will catch implicit system dependencies.
-* Discover and fix hermeticity problems using
- [remote execution rules](/remote/rules#overview).
-* Enable strict [sandboxing](/docs/sandboxing)
- at the per-action level, since actions in a build can be stateful and affect
- the build or the output.
-* [Workspace rules](/remote/workspace)
- allow developers to add dependencies to external workspaces, but they are
- rich enough to allow arbitrary processing to happen in the process. You can
- get a log of some potentially non-hermetic actions in Bazel workspace rules by
- adding the flag
- `--experimental_workspace_rules_log_file={{ '' }}PATH{{ '' }}` to
- your Bazel command.
-
-Note: Make your build fully hermetic when mixing remote and local execution,
-using Bazel’s “dynamic strategy” functionality. Running Bazel inside the remote
-Docker container will enable the build to execute the same in both environments.
-
-## Hermeticity with Bazel
-
-For more information about how other projects have had success using hermetic
-builds with Bazel, see these BazelCon talks:
-
-* [Building Real-time Systems with Bazel](https://www.youtube.com/watch?v=t_3bckhV_YI) (SpaceX)
-* [Bazel Remote Execution and Remote Caching](https://www.youtube.com/watch?v=_bPyEbAyC0s) (Uber and TwoSigma)
-* [Faster Builds With Remote Execution and Caching](https://www.youtube.com/watch?v=MyuJRUwT5LI)
-* [Fusing Bazel: Faster Incremental Builds](https://www.youtube.com/watch?v=rQd9Zd1ONOw)
-* [Remote Execution vs Local Execution](https://www.youtube.com/watch?v=C8wHmIln--g)
-* [Improving the Usability of Remote Caching](https://www.youtube.com/watch?v=u5m7V3ZRHLA) (IBM)
-* [Building Self Driving Cars with Bazel](https://www.youtube.com/watch?v=Gh4SJuYUoQI&list=PLxNYxgaZ8Rsf-7g43Z8LyXct9ax6egdSj&index=4&t=0s) (BMW)
-* [Building Self Driving Cars with Bazel + Q&A](https://www.youtube.com/watch?v=fjfFe98LTm8&list=PLxNYxgaZ8Rsf-7g43Z8LyXct9ax6egdSj&index=29) (GM Cruise)
diff --git a/8.0.1/basics/index.mdx b/8.0.1/basics/index.mdx
deleted file mode 100644
index f3c833f..0000000
--- a/8.0.1/basics/index.mdx
+++ /dev/null
@@ -1,57 +0,0 @@
----
-title: 'Build Basics'
----
-
-
-
-A build system is one of the most important parts of an engineering organization
-because each developer interacts with it potentially dozens or hundreds of times
-per day. A fully featured build system is necessary to enable developer
-productivity as an organization scales. For individual developers, it's
-straightforward to just compile your code and so a build system might seem
-excessive. But at a larger scale, having a build system helps with managing
-shared dependencies, such as relying on another part of the code base, or an
-external resource, such as a library. Build systems help to make sure that you
-have everything you need to build your code before it starts building. Build
-systems also increase velocity when they're set up to help engineers share
-resources and results.
-
-This section covers some history and basics of building and build systems,
-including design decisions that went into making Bazel. If you're
-familiar with artifact-based build systems, such as Bazel, Buck, and Pants, you
-can skip this section, but it's a helpful overview to understand why
-artifact-based build systems are excellent at enabling scale.
-
-Note: Much of this section's content comes from the _Build Systems and
-Build Philosophy_ chapter of the
-[_Software Engineering at Google_ book](https://abseil.io/resources/swe-book/html/ch18.html).
-Thank you to the original author, Erik Kuefler, for allowing its reuse and
-modification here!
-
-* **[Why a Build System?](/basics/build-systems)**
-
- If you haven't used a build system before, start here. This page covers why
- you should use a build system, and why compilers and build scripts aren't
- the best choice once your organization starts to scale beyond a few
- developers.
-
-* **[Task-Based Build Systems](/basics/task-based-builds)**
-
- This page discusses task-based build systems (such as Make, Maven, and
- Gradle) and some of their challenges.
-
-* **[Artifact-Based Build Systems](/basics/artifact-based-builds)**
-
- This page discusses artifact-based build systems in response to the pain
- points of task-based build systems.
-
-* **[Distributed Builds](/basics/distributed-builds)**
-
- This page covers distributed builds, or builds that are executed outside of
- your local machine. This requires more robust infrastructure to share
- resources and build results (and is where the true wizardry happens!)
-
-* **[Dependency Management](/basics/dependencies)**
-
- This page covers some complications of dependencies at a large scale and
- strategies to counteract those complications.
diff --git a/8.0.1/basics/task-based-builds.mdx b/8.0.1/basics/task-based-builds.mdx
deleted file mode 100644
index 9dd3f8c..0000000
--- a/8.0.1/basics/task-based-builds.mdx
+++ /dev/null
@@ -1,216 +0,0 @@
----
-title: 'Task-Based Build Systems'
----
-
-
-
-This page covers task-based build systems, how they work and some of the
-complications that can occur with task-based systems. After shell scripts,
-task-based build systems are the next logical evolution of building.
-
-
-## Understanding task-based build systems
-
-In a task-based build system, the fundamental unit of work is the task. Each
-task is a script that can execute any sort of logic, and tasks specify other
-tasks as dependencies that must run before them. Most major build systems in use
-today, such as Ant, Maven, Gradle, Grunt, and Rake, are task based. Instead of
-shell scripts, most modern build systems require engineers to create build files
-that describe how to perform the build.
-
-Take this example from the
-[Ant manual](https://ant.apache.org/manual/using.html):
-
-```xml
-| Command | -deps = | -
bazel build //myapp:mybinary --cpu=arm |
- [":arm_lib"] |
-
bazel build //myapp:mybinary -c dbg --cpu=x86 |
- [":x86_dev_lib"] |
-
bazel build //myapp:mybinary --cpu=ppc |
- [":generic_lib"] |
-
bazel build //myapp:mybinary -c dbg --cpu=ppc |
- [":generic_lib"] |
-