Args

An object that encapsulates, in a memory-efficient way, the data needed to build part or all of a command line.

It often happens that an action requires a large command line containing values accumulated from transitive dependencies. For example, a linker command line might list every object file needed by all of the libraries being linked. It is best practice to store such transitive data in depsets, so that they can be shared by multiple targets. However, if the rule author had to convert these depsets into lists of strings in order to construct an action command line, it would defeat this memory-sharing optimization.

For this reason, the action-constructing functions accept Args objects in addition to strings. Each Args object represents a concatenation of strings and depsets, with optional transformations for manipulating the data. Args objects do not process the depsets they encapsulate until the execution phase, when it comes time to calculate the command line. This helps defer any expensive copying until after the analysis phase is complete. See the Optimizing Performance page for more information.

Args are constructed by calling ctx.actions.args(). They can be passed as the arguments parameter of ctx.actions.run() or ctx.actions.run_shell(). Each mutation of an Args object appends values to the eventual command line.

The map_each feature allows you to customize how items are transformed into strings. If you do not provide a map_each function, the standard conversion is as follows:

• Values that are already strings are left as-is.
• File objects are turned into their File.path values.
• Label objects are turned into a string representation that resolves back to the same object when resolved in the context of the main repository. If possible, the string representation uses the apparent name of a repository in favor of the repository's canonical name, which makes this representation suited for use in BUILD files. While the exact form of the representation is not guaranteed, typical examples are //foo:bar, @repo//foo:bar and @@canonical_name~//foo:bar.bzl.
• All other types are turned into strings in an unspecified manner. For this reason, you should avoid passing values that are not of string or File type to add(), and if you pass them to add_all() or add_joined() then you should provide a map_each function.

When using string formatting (format, format_each, and format_joined params of the add*() methods), the format template is interpreted in the same way as %-substitution on strings, except that the template must have exactly one substitution placeholder and it must be %s. Literal percents may be escaped as %%. Formatting is applied after the value is converted to a string as per the above.

Each of the add*() methods have an alternate form that accepts an extra positional parameter, an "arg name" string to insert before the rest of the arguments. For add_all and add_joined the extra string will not be added if the sequence turns out to be empty. For instance, the same usage can add either --foo val1 val2 val3 --bar or just --bar to the command line, depending on whether the given sequence contains val1..val3 or is empty.

If the size of the command line can grow longer than the maximum size allowed by the system, the arguments can be spilled over into parameter files. See use_param_file() and set_param_file_format().

Example: Suppose we wanted to generate the command line:

--foo foo1.txt foo2.txt ... fooN.txt --bar bar1.txt,bar2.txt,...,barM.txt --baz

# foo_deps and bar_deps are depsets containing
# File objects for the foo and bar .txt files.
args = ctx.actions.args()
args.add_all("--foo", foo_deps)
args.add_joined("--bar", bar_deps, join_with=",")
args.add("--baz")
ctx.actions.run(
  ...
  arguments = [args],
  ...
)

Members

• add
• add_all
• add_joined
• set_param_file_format
• use_param_file

add

Args Args.add(arg_name_or_value, value=unbound, *, format=None)

Parameters

add_all

Args Args.add_all(arg_name_or_values, values=unbound, *, map_each=None, format_each=None, before_each=None, omit_if_empty=True, uniquify=False, expand_directories=True, terminate_with=None, allow_closure=False)

Most of the processing occurs over a list of arguments to be appended, as per the following steps:

1. Each directory File item is replaced by all Files recursively contained in that directory.
2. If map_each is given, it is applied to each item, and the resulting lists of strings are concatenated to form the initial argument list. Otherwise, the initial argument list is the result of applying the standard conversion to each item.
3. Each argument in the list is formatted with format_each, if present.
4. If uniquify is true, duplicate arguments are removed. The first occurrence is the one that remains.
5. If a before_each string is given, it is inserted as a new argument before each existing argument in the list. This effectively doubles the number of arguments to be appended by this point.
6. Except in the case that the list is empty and omit_if_empty is true (the default), the arg name and terminate_with are inserted as the first and last arguments, respectively, if they are given.

Parameters

add_joined

Args Args.add_joined(arg_name_or_values, values=unbound, *, join_with, map_each=None, format_each=None, format_joined=None, omit_if_empty=True, uniquify=False, expand_directories=True, allow_closure=False)

Processing is similar to add_all(), but the list of arguments derived from values is combined into a single argument as if by join_with.join(...), and then formatted using the given format_joined string template. Unlike add_all(), there is no before_each or terminate_with parameter since these are not generally useful when the items are combined into a single argument.

If after filtering there are no strings to join into an argument, and if omit_if_empty is true (the default), no processing is done. Otherwise if there are no strings to join but omit_if_empty is false, the joined string will be an empty string.

Parameters

set_param_file_format

Args Args.set_param_file_format(format)

Parameters

use_param_file

Args Args.use_param_file(param_file_arg, *, use_always=False)

Bazel may choose to elide writing the params file to the output tree during execution for efficiency. If you are debugging actions and want to inspect the param file, pass --materialize_param_files to your build.

Parameters