| commit | dac0d40d0eb903f5cb70341398d1a333c19adf3a | [log] [tgz] |
|---|---|---|
| author | Googler <noreply@google.com> | Wed Jan 13 06:56:57 2021 -0800 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Jan 13 06:59:21 2021 -0800 |
| tree | 07378de6d5944ab6a0092cb91f5a0c215cd6d483 | |
| parent | 082d98772690946ed29c157e60640c97a6e1195b [diff] |
Improve "Common Attributes" section Creates a separate section for attributes which are added to most build rules, but not implicitly added to Starlark rules. deps, data, and licenses are moved to that section. srcs is also added to the new section, since I think that's as notable a naming convention to highlight as "deps" and "data". The section on "deps" is updated to note: * That "deps" generally should contain only specific rules and not files * How "deps" generally varies between language specific rules * The general relationship between "srcs" and "deps". Also, a bit that says "deps" are always included in runfiles is removed. That's not even usually true. Though it may be true in some cases that source code is needed at runtime and therefore should be included in runfiles (this could be the case for build rules for some interpreted languages, for example), often source code is not needed at runtime and shouldn't be included in runfiles. The section on "data" is updated to note: * That generally "data" permits arbitrary dependencies * That default outputs and runfiles from targets in data should be included in the runfiles of consumers * The general relationship between "data" and "srcs" * What Starlark rules need to do to handle data in their implementation functions The remainder of the section is updated to: * Consistently use "target" instead of "rule" to refer to rule targets. "Rule target" is unnecessary, file targets don't have attributes * Use a consistent format the type of the attribute * Consistently omit that optional list or dictionary attributes default to empty lists or dictionaries * Use False instead of 0 for the default values of attributes whose type is "boolean" And did a bit of copyediting. A line from the introduction to the "common attributes" section that mentions it's an error to list the same label twice in a label-list attribute is pruned. That's true, but it seems misplaced here, it's not very related to the rest of this section. "applicable_licenses" and "transitive_configs" are not yet documented. RELNOTES: None. PiperOrigin-RevId: 351577116
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
See CONTRIBUTING.md
