Basel
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.
Bazel is an open source, supports multiple languages, cross-platform, with the Make a similar compilation tools.
- Official website: https://www.bazel.build
- Github: https://github.com/bazelbuild/bazel
installation
- Please refer to the installation process: http://bazel.io/docs/install.html
- Mac OSX 下：
brew install bazel - Under Linux:
yum install bazel
Examples of official
First cloning project:
:git clone https://github.com/bazelbuild/examples
正克隆到 'examples'...
remote: Enumerating objects: 14, done.
remote: Counting objects: 100% (14/14), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 1183 (delta 3), reused 6 (delta 2), pack-reused 1169
接收对象中: 100% (1183/1183), 362.71 KiB | 113.00 KiB/s, 完成.
处理 delta 中: 100% (439/439), 完成.
examples provided in multiple languages, look at the cpp:
:cd examples/cpp-tutorial
To see which files are under the directory:
:tree
.
├── README.md
├── stage1
│ ├── README.md
│ ├── WORKSPACE
│ └── main
│ ├── BUILD
│ └── hello-world.cc
├── stage2
│ ├── README.md
│ ├── WORKSPACE
│ └── main
│ ├── BUILD
│ ├── hello-greet.cc
│ ├── hello-greet.h
│ └── hello-world.cc
└── stage3
├── README.md
├── WORKSPACE
├── lib
│ ├── BUILD
│ ├── hello-time.cc
│ └── hello-time.h
└── main
├── BUILD
├── hello-greet.cc
├── hello-greet.h
└── hello-world.cc
7 directories, 20 files
As you can see, there are three sets of files, each set representing a stage in this tutorial. In the first stage, you will build a single target residing in a single package. In the second stage, you will split your project into multiple targets but keep it in a single package. In the third and final stage, you will split your project into multiple packages and build it with multiple targets.
First of all there is to see WORKSPACE a predetermined area, then there BUILD file defines the rules to compile different files.
Set 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 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, 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.)
WORKSPACE file used to distinguish one project, it should be located in the root directory of the project.
How to define one or more BUILD file compile a project in different modules.
To designate a directory as a Bazel workspace, create an empty file named WORKSPACE 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.
Bazel when compiling the project, all of the input and dependent files should be in the same workspace (workspace), and if there is no link at different workspaces, then, there is no way to compile Bazel.
BUILD
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.
BUILD file that contains a different type of instructions Bazel, the most important thing is to compile rules that specify how the output (such as executable binaries or libraries). Compile a rule is a goal that points to multiple source files and dependent files, you can also point to another target.
for example:
cc_binary(
name = "hello-world",
srcs = ["hello-world.cc"],
)
the hello-world target instantiates Bazel’s built-in cc_binary rule. The rule tells Bazel to build a self-contained executable binary from the hello-world.cc source file with no dependencies.
Cc_binary above defines a type of name for the compilation rules hello-world, it will hello-world.cc file is compiled into an executable file.
Compile the project Build the project
Command is as follows:
bazel build //main:hello-world
Notice the target label - the //main: part is the location of our BUILD file relative to the root of the workspace, and hello-world is what we named that target in the BUILD file. (You will learn about target labels in more detail at the end of this tutorial.)
// Build path Bazel / to / Package Penalty for: target-name
Bazel Build // relative to the workspace directory: Rule name
Execution:
:cd stage1
:bazel build //main:hello-world
Starting local Bazel server and connecting to it...
INFO: Analyzed target //main:hello-world (13 packages loaded, 49 targets configured).
INFO: Found 1 target...
Target //main:hello-world up-to-date:
bazel-bin/main/hello-world
INFO: Elapsed time: 31.900s, Critical Path: 1.47s
INFO: 2 processes: 2 darwin-sandbox.
INFO: Build completed successfully, 5 total actions
If you want to run the file:
bazel-bin/main/hello-world
After a look at what had bazel build file:
:cd stage1
:ls
README.md WORKSPACE bazel-bin bazel-out bazel-stage1 bazel-testlogs main
:tree
.
├── README.md
├── WORKSPACE
├── bazel-bin -> /private/var/tmp/_bazel_lurongming/f341b2c050b4058e9d9fef7c2d35da5d/execroot/__main__/bazel-out/darwin-fastbuild/bin
├── bazel-out -> /private/var/tmp/_bazel_lurongming/f341b2c050b4058e9d9fef7c2d35da5d/execroot/__main__/bazel-out
├── bazel-stage1 -> /private/var/tmp/_bazel_lurongming/f341b2c050b4058e9d9fef7c2d35da5d/execroot/__main__
├── bazel-testlogs -> /private/var/tmp/_bazel_lurongming/f341b2c050b4058e9d9fef7c2d35da5d/execroot/__main__/bazel-out/darwin-fastbuild/testlogs
└── main
├── BUILD
└── hello-world.cc
5 directories, 4 files
Review
:bazel query --notool_deps --noimplicit_deps 'deps(//main:hello-world)' --output graph
digraph mygraph {
node [shape=box];
"//main:hello-world"
"//main:hello-world" -> "//main:hello-world.cc"
"//main:hello-world.cc"
}
Use bazel query can query compilation rules.
Let's look at a bit more complex:
└── stage3
├── README.md
├── WORKSPACE
├── lib
│ ├── BUILD
│ ├── hello-time.cc
│ └── hello-time.h
└── main
├── BUILD
├── hello-greet.cc
├── hello-greet.h
└── hello-world.cc
It's compilation rules:
lib/BUILD：
cc_library(
name = "hello-time",
srcs = ["hello-time.cc"],
hdrs = ["hello-time.h"],
visibility = ["//main:__pkg__"],
)
main/BUILD：
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",
],
)
Notice that for the build to succeed, we 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.)
The default BUILD file only goal in this document can only be seen if other BUILD need to see that, please use visibility.
