Download and install: wget https://github.com/bazelbuild/bazel/releases/download/0.18.0/bazel-0.18.0-installer-linux-x86_64.sh
Examples of common libraries compiled with bazel
https://github.com/bazelment/trunk
Can be viewed in order
- https://docs.bazel.build/versions/master/getting-started.html
- https://docs.bazel.build/versions/master/tutorial/cpp.html
- https://docs.bazel.build/versions/master/cpp-use-cases.html
- https://docs.bazel.build/versions/master/external.html
- https://docs.bazel.build/versions/master/rules.html
- https://docs.bazel.build/versions/master/bazel-and-cpp.html
- https://docs.bazel.build/versions/master/be/overview.html
- https://docs.bazel.build/versions/master/command-line-reference.html
- https://docs.bazel.build/versions/master/skylark/testing.html
- https://docs.bazel.build/versions/master/be/general.html
- https://docs.bazel.build/versions/master/best-practices.html
Study notes for interested people (Chinese version)
https://blog.gmem.cc/bazel-study-note
package: A directory within the workspace that contains a BUILD file is a package.
package_group: Package groups are sets of packages whose purpose is to limit accessibility of certain rules.
label: All targets belong to exactly one package. The name of a target is called its label, every label uniquely identifies a target.
label syntax: //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 within the same package, you can skip the package path and 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.
Labels start with "//", but package names never do, thus "my/app" is the package containing "//my/app".
content
|
definition
|
link
|
---|---|---|
Bazel概念(workspace、package、target) | workspace: package: A directory within the workspace that contains a target: Each instance of a build rule in the |
https://docs.bazel.build/versions/0.27.0/build-ref.html |
Bazel command line parameters | https://docs.bazel.build/versions/0.27.0/guide.html | |
Bazel external dependencies | https://docs.bazel.build/versions/0.27.0/external.html https://docs.bazel.build/versions/0.27.0/best-practices.html#depending-on-binaries |
View dependency graph
bazel query --noimplicit_deps 'deps(//main:hello-world)' --output graph
sudo apt update && sudo apt install graphviz xdot
xdot <(bazel query --noimplicit_deps 'deps(//main:hello-world)' --output graph)
Common rules
cc_binary
cc_library
cc_proto_library
Other rules
filegroup gives a convenient name to a target collection
config_setting ??? https://docs.bazel.build/versions/master/be/general.html#config_setting
Common attributes in rules
srcs: specify the source file, you can also add a binary file
outs:
hdrs: specify header files
copts: Specify compilation options, such as "-I <include-paths>"
linkopts: Specify link options, such as "-pthread"
visibility: Specifies the visibility of the target. By default, the target in the same BUILD file is visible
strip_prefix: remove prefix
deps: dependent
Fixed routine, load bazel extension
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
load("@bazel_tools//tools/build_defs/repo:git.bzl", "new_git_repository")
The relationship between factual dependence and declarative dependence
A target X is actually dependent on target Y if and only if Y must be present, built and up-to-date in order for X to be built correctly. "Built" could mean generated, processed, compiled, linked, archived, compressed, executed, or any of the other kinds of tasks that routinely occur during a build.
A target X has a declared dependency on target Y if and only if there is a dependency edge from X to Y in the package of X.
For correct builds, the graph of actual dependencies A must be a subgraph of the graph of declared dependencies D.
Three common dependencies
srcs: Files consumed directly by the rule or rules that output source files.
deps: Rule pointing to separately-compiled modules providing header files, symbols, libraries, data, etc.
data: such as the data needed for unit testing
To ensure the accuracy of the incremental build, it is best to let bazel grasp the complete set of input files, not the directory.
You can use the glob function for convenience, "**" can force its recursion.
data = glob(["testdata/**"]) # use this instead
Directory labels can only be used in data dependencies, other dependency types are not allowed.
Modify bazel's cache directory
bazel --output_user_root=/path/to/directory build //foo:bar
bazelrc
https://docs.bazel.build/versions/master/best-practices.html#bazelrc
https://docs.bazel.build/versions/master/guide.html#bazelrc
bazel compiled debuggable version
bazel build xxx -c dbg