According to https://docs.bazel.build/versions/master/query-how-to.html#What_build_rule_contains_file_ja,
fullname=$(bazel query path/to/file/bar.java)
bazel query "attr('srcs', $fullname, ${fullname//:*/}:*)"
will tell me which target bar.java belongs to.
How can I get the set of targets that multiple files belong to? I.e. map set(files) -> set(targets). I could do this in serial, but each bazel call is fairly expensive and slow---I want to get it done in one call.
Context: I'd like to do this (build targets pertaining to a few files):
git diff HEAD~ | xargs bazel query "get targets for set(files)" | xargs bazel build
I feel like this capability must already exist, but I haven't been able to find it.
Using query will work, but you can also use aquery for a more direct approach.
https://docs.bazel.build/versions/master/aquery.html
BUILD:
genrule(
name = "gen1",
srcs = ["a"],
outs = ["gen1.out"],
cmd = "echo foo > $#",
)
pkg/BUILD:
genrule(
name = "gen2",
srcs = ["b"],
outs = ["gen2.out"],
cmd = "echo foo > $#",
)
$ bazel aquery "inputs('a|pkg/b', ...)" --include_artifacts=false --include_commandline=false
INFO: Analyzed 2 targets (6 packages loaded, 10 targets configured).
INFO: Found 2 targets...
action 'Executing genrule //pkg:gen2'
Mnemonic: Genrule
Target: //pkg:gen2
Configuration: k8-fastbuild
ActionKey: 8d7d05620bfd8303aa66488e0cd6586d8e978197126cdb41c5fc8c49c81988ef
action 'Executing genrule //:gen1'
Mnemonic: Genrule
Target: //:gen1
Configuration: k8-fastbuild
ActionKey: d4c76a6b6913ce5d887829dbc00d101c1cf5b0ff5240ed13ea328c26e4b41960
INFO: Elapsed time: 0.198s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions
inputs (like attr) accepts a regular expression, so you can "or" the files together with |. Then just filter for Target:, or use one of the other outputs (--output=(proto|textproto|jsonproto))
This has the advantages that:
you don't need to figure out the labels of the files first (since attr in query operates on labels).
aquery queries after the analysis phase, so your results are more accurate because it accounts for configuration (flags, etc).
this will work for any attribute, since it's querying the inputs of all actions, which is at a lower level than rules
On the other hand, since aquery runs loading + analysis, it might take longer than query, since query just runs the loading phase.
Related
I had this genrule in BUILD file, but bazel build failed for the error of:
in cmd attribute of genrule rule //example:create_version_pom: $(BUILD_TAG) not defined
genrule(
name = "create_version_pom",
srcs = ["pom_template.xml"],
outs = ["version_pom.xml"],
cmd = "sed 's/BUILD_TAG/$(BUILD_TAG)/g' $< > $#",
)
What's the reason, and how to fix it please?
The cmd attribute of genrule will do variable expansion for Bazel build variables before the command is executed. The $< and $# variables for the input file and the output file are some of the pre-defined variables. Variables can be defined with --define, e.g.:
$ cat BUILD
genrule(
name = "genfoo",
outs = ["foo"],
cmd = "echo $(bar) > $#",
)
$ bazel build foo --define=bar=123
INFO: Analyzed target //:foo (5 packages loaded, 8 targets configured).
INFO: Found 1 target...
Target //:foo up-to-date:
bazel-bin/foo
INFO: Elapsed time: 0.310s, Critical Path: 0.01s
INFO: 2 processes: 1 internal, 1 linux-sandbox.
INFO: Build completed successfully, 2 total actions
$ cat bazel-bin/foo
123
So to have $(BUILD_TAG) work in the genrule, you'll want to pass
--define=BUILD_TAG=the_build_tag
Unless it's that you want BUILD_TAG replaced with literally $(BUILD_TAG), in which case the $ needs to be escaped with another $: $$(BUILD_TAG).
See
https://docs.bazel.build/versions/main/be/general.html#genrule.cmd
https://docs.bazel.build/versions/main/be/make-variables.html
Note that Bazel also has a mechanism for "build stamping" for bringing information like build time and version numbers into the build:
https://docs.bazel.build/versions/main/user-manual.html#workspace_status
https://docs.bazel.build/versions/main/command-line-reference.html#flag--embed_label
Using --workspace_status_command and --embed_label are a little more complicated though.
I am trying to reference an output of a rule that is nested inside an output directory of another rule in a genrule.
For example, I use rules_foreign_cc to build boost:
boost_build(
name = "boost",
lib_source = "#boost//:all",
linkopts = [
"-lpthread",
],
shared_libraries = [
"libboost_chrono.so.1.72.0",
"libboost_program_options.so.1.72.0",
"libboost_filesystem.so.1.72.0",
"libboost_system.so.1.72.0",
"libboost_thread.so.1.72.0",
"libboost_timer.so.1.72.0",
],
user_options = [
"cxxstd=17",
"--with-chrono",
"--with-filesystem",
"--with-program_options",
"--with-system",
"--with-thread",
"--with-timer",
"-j4",
],
)
And when I build it, I see the outputs:
bazel build //:boost
INFO: Invocation ID: 36440de3-15f2-4ca0-8802-0a95f75ed926
INFO: Analyzed target //:boost (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //:boost up-to-date:
bazel-bin/boost/include
bazel-bin/boost/lib/libboost_chrono.so.1.72.0
bazel-bin/boost/lib/libboost_program_options.so.1.72.0
bazel-bin/boost/lib/libboost_filesystem.so.1.72.0
bazel-bin/boost/lib/libboost_system.so.1.72.0
bazel-bin/boost/lib/libboost_thread.so.1.72.0
bazel-bin/boost/lib/libboost_timer.so.1.72.0
bazel-bin/copy_boost/boost
bazel-bin/boost/logs/BuildBoost_script.sh
bazel-bin/boost/logs/BuildBoost.log
bazel-bin/boost/logs/wrapper_script.sh
INFO: Elapsed time: 0.758s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
Boost works properly, I can reference it in cc_library targets and binaries run fine.
Now, I would like to reference one of the outputs in a genrule. The file I want to reference is nested inside the boost/lib/ directory. I would expect something like: $(location :boost/lib/libboost_program_options.so.1.72.0), but that doesn't work.
What's the proper way to reference the outputs in the directory?
This is what I did, hope it helps.
Inside your genrule, create a variable that hold the output array of your boost rule, use $(locations) instead of $(location). Then loop through the array and find the path you want to use later.
BOOST_OUTPUTS=( $(locations boost) )
LIBBOOST_CHRONO_SO=
for i in "$${{BOOST_OUTPUTS[#]}}"
do
if [[ "$$i" == *"libboost_chrono.so.1.72.0"* ]]; then
LIBBOOST_CHRONO_SO="$$i"
fi
done
# Do something with LIBBOOST_CHRONO_SO
Just note that $$ and {{ and }} are for escaping special characters.
I have set up bazel to build a number of CLI tools that perform various database maintenance tasks. Each one is a py_binary or cc_binary target that is called from the command line with the path to some data file: it processes that file and stores the results in a database.
Now, I need to create a dependent package that contains data files and shell scripts that call these CLI tools to perform application-specific database operations.
However, there doesn't seem to be a way to depend on the existing py_binary or cc_binary targets from a new package that only contains sh_binary targets and data files. Trying to do so results in an error like:
ERROR: /workspace/shbin/BUILD.bazel:5:12: in deps attribute of sh_binary rule //shbin:run: py_binary rule '//pybin:counter' is misplaced here (expected sh_library)
Is there a way to call/depend on an existing bazel binary target from a shell script using sh_binary?
I have implemented a full example here:
https://github.com/psigen/bazel-mixed-binaries
Notes:
I cannot use py_library and cc_library instead of py_binary and cc_binary. This is because (a) I need to call mixes of the two languages to process my data files and (b) these tools are from an upstream repository where they are already designed as CLI tools.
I also cannot put all the data files into the CLI tool packages -- there are multiple application-specific packages and they cannot be mixed.
You can either create a genrule to run these tools as part of the build, or create a sh_binary that depends on the tools via the data attribute and runs them them.
The genrule approach
This is the easier way and lets you run the tools as part of the build.
genrule(
name = "foo",
tools = [
"//tool_a:py",
"//tool_b:cc",
],
srcs = [
"//source:file1",
":file2",
],
outs = [
"output_file1",
"output_file2",
],
cmd = "$(location //tool_a:py) --input=$(location //source:file1) --output=$(location output_file1) && $(location //tool_b:cc) < $(location :file2) > $(location output_file2)",
)
The sh_binary approach
This is more complicated, but lets you run the sh_binary either as part of the build (if it is in a genrule.tools, similar to the previous approach) or after the build (from under bazel-bin).
In the sh_binary you have to data-depend on the tools:
sh_binary(
name = "foo",
srcs = ["my_shbin.sh"],
data = [
"//tool_a:py",
"//tool_b:cc",
],
)
Then, in the sh_binary you have to use the so-called "Bash runfiles library" built into Bazel to look up the runtime-path of the binaries. This library's documentation is in its source file.
The idea is:
the sh_binary has to depend on a specific target
you have to copy-paste some boilerplate code to the top of the sh_binary (reason is described here)
then you can use the rlocation function to look up the runtime-path of the binaries
For example your my_shbin.sh may look like this:
#!/bin/bash
# --- begin runfiles.bash initialization ---
...
# --- end runfiles.bash initialization ---
path=$(rlocation "__main__/tool_a/py")
if [[ ! -f "${path:-}" ]]; then
echo >&2 "ERROR: could not look up the Python tool path"
exit 1
fi
$path --input=$1 --output=$2
The __main__ in the rlocation path argument is the name of the workspace. Since your WORKSPACE file does not have a "workspace" rule in, which would define the workspace's name, Bazel will use the default workspace name, which is __main__.
An easier approach for me is to add the cc_binary as a dependency in the data section. In prefix/BUILD
cc_binary(name = "foo", ...)
sh_test(name = "foo_test", srcs = ["foo_test.sh"], data = [":foo"])
Inside foo_test.sh, the working directory is different, so you need to find the right prefix for the binary
#! /usr/bin/env bash
executable=prefix/foo
$executable ...
A clean way to do this is to use args and $(location):
Contents of BUILD:
py_binary(
name = "counter",
srcs = ["counter.py"],
main = "counter.py",
)
sh_binary(
name = "run",
srcs = ["run.sh"],
data = [":counter"],
args = ["$(location :counter)"],
)
Contents of counter.py (your tool):
print("This is the counter tool.")
Contents of run.sh (your bash script):
#!/bin/bash
set -eEuo pipefail
counter="$1"
shift
echo "This is the bash script, about to call the counter tool."
"$counter"
And here's a demo showing the bash script calling the Python tool:
$ bazel run //example:run 2>/dev/null
This is the bash script, about to call the counter tool.
This is the counter tool.
It's also worth mentioning this note (from the docs):
The arguments are not passed when you run the target outside of bazel (for example, by manually executing the binary in bazel-bin/).
We're using Bazel at work for wrapping and organizing some build systems that we use for our projects. Since, each project has its own build system (like bitbake for example), we can't use Bazel for the actual building (e.g creating cc_binary and cc_library rules that contain all the source code). But we do use it for wrapping and for a uniformed API.
I want to make a shell script (A) dependent of another shell script (B), and I want to do so, such that B will run before A. Since we have some configurations inside the BUILD files, I can't simply run from command line B then A. I need Bazel to do so, and inject the configuration to both scripts. Something like :
In the BUILD file of one component:
sh_binary(
name = "bazel_build_multivisor",
srcs = ["bazel-build-multivisor.sh"],
data = ["wrkspceinfo"],
deps = ["//core-build/components/bazel-pull:bazel_pull_multivisor"])
In the BUILD file of a second component which is in charge of pulling from git:
sh_binary(
name = "bazel_pull_multivisor",
srcs = ["pull_repo_repository.sh"],
data = ["wrkspceinfo", "pull_repo_repository.sh"],
args = [ARGS, "NAME=multivisor_repo;MODULE_NAME=*;GIT_BRANCH=*;MANIFEST=*.xml;PULL_PARAMS=8,8,8"],)
Meaning, I want a sh_binary rule to depend on a different sh_binary rule.
Is this possible? Is there a better way doing so?
Thanks.
Consider using a genrule.
You can specify both sh_binary targets in the genrule.tools attribute, and then in the genrule.cmd attribute, specify the shell command that calls them in order.
For example,
genrule(
name = "pull_and_build",
srcs = "some_config_file.txt",
outs = ["built_project.tar.gz"]
tools = [":pull_sh", ":build_sh"],
cmd = """
$(location :pull_sh) $< | \
xargs -1 $(location :build_sh) | \
xargs -1 tar -czvf $#"""
)
Another possible way is to wrap the dependency sh_binary in a sh_library instead, and aggregate them at the top level sh_binary.
I'm looking for a good recipe to run "checks" or "verify" steps in Bazel, like go vet, gofmt, pylint, cppcheck. These steps don't create any output file. The only thing that matters is the return code (like a test).
Right now I'm using the following recipe:
sh_test(
name = "verify-pylint",
srcs = ["verify-pylint.sh"],
data = ["//:all-srcs"],
)
And verify-pylint.sh looks like this:
find . -name '*.py' | xargs pylint
This has two problems:
The verify logic is split between the shell script and the BUILD file. Ideally I would like to have both in the same place (in the BUILD file)
Anytime one of the source file changes (in //:all-srcs), bazel test verify-pylint re-runs pylint on every single file (and that can be expensive/slow).
What is the idiomatic way in bazel to run these steps?
There are more than one solutions.
The cleanest way is to do the verification at build time: you create a genrule for each file (or batch of files) you want to verify, and if verification succeeds, the genrule outputs something, if it fails, then the rule outputs nothing, which automatically fails the build as well.
Since success of verification depends on the file's contents, and the same input should yield the same output, the genrules should produce an output file that's dependent on the contents of the input(s). The most convenient thing is to write the digest of the file(s) to the output if verification succeeded, and no output if verification fails.
To make the verifier reusable, you could create a Skylark macro and use it in all your packages.
To put this all together, you'd write something like the following.
Contents of //tools:py_verify_test.bzl:
def py_verify_test(name, srcs, visibility = None):
rules = {"%s-file%d" % (name, hash(s)): s for s in srcs}
for rulename, src in rules.items():
native.genrule(
name = rulename,
srcs = [s],
outs = ["%s.md5" % rulename],
cmd = "$(location //tools:py_verifier) $< && md5sum $< > $#",
tools = ["//tools:py_verifier"],
visibility = ["//visibility:private"],
)
native.sh_test(
name = name,
srcs = ["//tools:build_test.sh"],
data = rules.keys(),
visibility = visibility,
)
Contents of //tools:build_test.sh:
#!/bin/true
# If the test rule's dependencies could be built,
# then all files were successfully verified at
# build time, so this test can merely return true.
Contents of //tools:BUILD:
# I just use sh_binary as an example, this could
# be a more complicated rule of course.
sh_binary(
name = "py_verifier",
srcs = ["py_verifier.sh"],
visibility = ["//visibility:public"],
)
Contents of any package that wants to verify files:
load("//tools:py_verify_test.bzl", "py_verify_test")
py_verify_test(
name = "verify",
srcs = glob(["**/*.py"]),
)
A simple solution.
In your BUILD file:
load(":gofmt.bzl", "gofmt_test")
gofmt_test(
name = "format_test",
srcs = glob(["*.go"]),
)
In gofmt.bzl:
def gofmt_test(name, srcs):
cmd = """
export TMPDIR=.
out=$$(gofmt -d $(SRCS))
if [ -n "$$out" ]; then
echo "gmfmt failed:"
echo "$$out"
exit 1
fi
touch $#
"""
native.genrule(
name = name,
cmd = cmd,
srcs = srcs,
outs = [name + ".out"],
tools = ["gofmt.sh"],
)
Some remarks:
If your wrapper script grows, you should put it in a separate .sh file.
In the genrule command, we need $$ instead $ due to escaping (see documentation)
gofmt_test is actually not a test and will run with bazel build :all. If you really need a test, see Laszlo's example and call sh_test.
I call touch to create a file because genrule requires an output to succeed.
export TMPDIR=. is needed because by default the sandbox prevents writing in other directories.
To cache results for each file (and avoid rechecking a file that hasn't changed), you'll need to create multiple actions. See Laszlo's for loop.
To simplify the code, we could provide a generic rule. Maybe this is something we should put in a standard library.