Common usage of bazel

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

 

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 BUILD file is a package.

target: 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.

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

Guess you like

Origin www.cnblogs.com/anhongyu/p/12727707.html