1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
---
layout: documentation
title: Bazel Vision
---
# Bazel Vision
<font size='+1'>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.</font>
* **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.
### So what is 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://bazel.build/designs/2016/08/04/extensibility-for-native-rules.html)
principles.
1. The rules need to be **remote-execution ready**. In practice, this means
**configurable using the
[toolchains](https://docs.bazel.build/versions/master/toolchains.html)
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.
|
