API reference#
- class pw_cc_toolchain#
This rule is the core of a C/C++ toolchain definition. Critically, it is intended to fully specify the following:
Which tools to use for various compile/link actions.
Which well-known features are supported.
Which flags to apply to various actions.
- feature_deps: List[label]#
pw_cc_toolchain_feature
labels that provide features for this toolchain.
- ar: File#
Path to the tool to use for
ar
(static link) actions.
- cpp: File#
Path to the tool to use for C++ compile actions.
- gcc: File#
Path to the tool to use for C compile actions.
- gcov: File#
Path to the tool to use for generating code coverage data.
- ld: File#
Path to the tool to use for link actions.
- strip: File#
Path to the tool to use for strip actions.
- objcopy: File#
Path to the tool to use for objcopy actions.
- objdump: File#
Path to the tool to use for objdump actions.
- action_config_flag_sets: List[label]#
List of flag sets to apply to the respective
action_config
s. The vast majority of labels listed here will point topw_cc_flag_set
rules.
- toolchain_identifier: str#
- host_system_name: str#
- target_system_name: str#
- target_cpu: str#
- target_libc: str#
- compiler: str#
- abi_version: str#
- abi_libc_version: str#
- cc_target_os: str#
- builtin_sysroot: str#
- cxx_builtin_include_directories: List[str]#
- class pw_cc_flag_set#
Declares an ordered set of flags bound to a set of actions.
Flag sets can be attached to a
pw_cc_toolchain
viapw_cc_toolchain.action_config_flag_sets
.Examples:
pw_cc_flag_set( name = "warnings_as_errors", flags = ["-Werror"], ) pw_cc_flag_set( name = "layering_check", flag_groups = [ ":strict_module_headers", ":dependent_module_map_files", ], )
Note: In the vast majority of cases, alphabetical sorting is not desirable for the
pw_cc_flag_set.flags
andpw_cc_flag_set.flag_groups
attributes. Buildifier shouldn’t ever try to sort these, but in the off chance it starts to these members should be listed as exceptions in theSortableDenylist
.- actions: List[str]#
A list of action names that this flag set applies to.
Valid choices are listed at @rules_cc//cc:action_names.bzl.
It is possible for some needed action names to not be enumerated in this list, so there is not rigid validation for these strings. Prefer using constants rather than manually typing action names.
- flags: List[str]#
Flags that should be applied to the specified actions.
These are evaluated in order, with earlier flags appearing earlier in the invocation of the underlying tool. If you need expansion logic, prefer enumerating flags in a
pw_cc_flag_group
or create a custom rule that providesFlagGroupInfo
.Note:
pw_cc_flag_set.flags
andpw_cc_flag_set.flag_groups
are mutually exclusive.
- flag_groups: List[label]#
Labels pointing to
pw_cc_flag_group
rules.This is intended to be compatible with any other rules that provide
FlagGroupInfo
. These are evaluated in order, with earlier flag groups appearing earlier in the invocation of the underlying tool.Note:
pw_cc_flag_set.flag_groups
andpw_cc_flag_set.flags
are mutually exclusive.
- class pw_cc_flag_group#
Declares an (optionally parametric) ordered set of flags.
pw_cc_flag_group
rules are expected to be consumed exclusively bypw_cc_flag_set
rules. Though simple lists of flags can be expressed by populatingflags
on apw_cc_flag_set
,pw_cc_flag_group
provides additional power in the following two ways:Iteration and conditional expansion. Using
pw_cc_flag_group.iterate_over
,pw_cc_flag_group.expand_if_available
, andpw_cc_flag_group.expand_if_not_available
, more complex flag expressions can be made. This is critical for implementing things like thelibraries_to_link
feature, where library names are transformed into flags that end up in the final link invocation.Note:
expand_if_equal
,expand_if_true
, andexpand_if_false
are not yet supported.Flags are tool-independent. A
pw_cc_flag_group
expresses ordered flags that may be reused across variouspw_cc_flag_set
rules. This is useful for cases where multiplepw_cc_flag_set
rules must be created to implement a feature for which flags are slightly different depending on the action (e.g. compile vs link). Common flags can be expressed in a sharedpw_cc_flag_group
, and the differences can be relegated to separatepw_cc_flag_group
instances.
Examples:
pw_cc_flag_group( name = "user_compile_flag_expansion", flags = ["%{user_compile_flags}"], iterate_over = "user_compile_flags", expand_if_available = "user_compile_flags", ) # This flag_group might be referenced from various FDO-related # `pw_cc_flag_set` rules. More importantly, the flag sets pulling this in # may apply to different sets of actions. pw_cc_flag_group( name = "fdo_profile_correction", flags = ["-fprofile-correction"], expand_if_available = "fdo_profile_path", )
- flags: List[str]#
List of flags provided by this rule.
For extremely complex expressions of flags that require nested flag groups with multiple layers of expansion, prefer creating a custom rule in Starlark that provides
FlagGroupInfo
orFlagSetInfo
.
- iterate_over: str#
Expands
pw_cc_flag_group.flags
for items in the named list.Toolchain actions have various variables accessible as names that can be used to guide flag expansions. For variables that are lists,
pw_cc_flag_group.iterate_over
must be used to expand the list into a series of flags.Note that
pw_cc_flag_group.iterate_over
is the string name of a build variable, and not an actual list. Valid options are listed in the C++ Toolchain Configuration reference.Note that the flag expansion stamps out the entire list of flags in
pw_cc_flag_group.flags
once for each item in the list.Example:
# Expands each path in ``system_include_paths`` to a series of # ``-isystem`` includes. # # Example input: # system_include_paths = ["/usr/local/include", "/usr/include"] # # Expected result: # "-isystem /usr/local/include -isystem /usr/include" pw_cc_flag_group( name = "system_include_paths", flags = ["-isystem", "%{system_include_paths}"], iterate_over = "system_include_paths", )
- expand_if_available: str#
Expands the expression in
pw_cc_flag_group.flags
if the specified build variable is set.
- expand_if_not_available: str#
Expands the expression in
pw_cc_flag_group.flags
if the specified build variable is NOT set.
- class pw_cc_tool#
Declares a singular tool that can be bound to action configs.
pw_cc_tool
rules are intended to be consumed exclusively bypw_cc_action_config
rules. These rules declare an underlying tool that can be used to fulfill various actions. Many actions may reuse a shared tool.Note:
with_features
is not yet supported.Examples:
# A project-provided tool. pw_cc_tool( name = "clang_tool", tool = "@llvm_toolchain//:bin/clang", ) # A tool expected to be preinstalled on a user's machine. pw_cc_tool( name = "clang_tool", path = "/usr/bin/clang", )
- tool: label#
The underlying tool that this rule represents.
This attribute is a label rather than a simple file path. This means that the file must be referenced relative to the BUILD file that exports it. For example:
@llvm_toolchain//:bin/clang ^ ^ ^
Where:
@llvm_toolchain
is the repository.//
is the directory of the BUILD file that exports the file of interest.bin/clang
is the path of the actual binary relative to the BUILD file of interest.
Note:
pw_cc_tool.tool
andpw_cc_tool.path
are mutually exclusive.
- path: Path#
An absolute path to a binary to use for this tool.
Relative paths are also supported, but they are relative to the
pw_cc_toolchain
that uses this tool rather than relative to thispw_cc_tool
rule.Note:
pw_cc_tool.path
andpw_cc_tool.tool
are mutually exclusive.Note
This method of listing a tool is NOT recommended, and is provided as an escape hatch for edge cases. Prefer using
pw_cc_tool.tool
whenever possible.
- execution_requirements: List[str]#
A list of strings that provide hints for execution environment compatibility (e.g.
requires-darwin
).
- class pw_cc_action_config#
Declares the configuration and selection of pw_cc_tool rules.
Action configs are bound to a toolchain through action_configs, and are the driving mechanism for controlling toolchain tool invocation/behavior.
Action configs define three key things:
Which tools to invoke for a given type of action.
Tool features and compatibility.
pw_cc_flag_set
s that are unconditionally bound to a tool invocation.
Examples:
pw_cc_action_config( name = "ar", action_names = ALL_AR_ACTIONS, implies = [ "archiver_flags", "linker_param_file", ], tools = [":ar_tool"], ) pw_cc_action_config( name = "clang", action_names = ALL_ASM_ACTIONS + ALL_C_COMPILER_ACTIONS, tools = [":clang_tool"], )
- action_names: List[str]#
A list of action names to apply this action to.
Valid choices are listed at @rules_cc//cc:action_names.bzl.
It is possible for some needed action names to not be enumerated in this list, so there is not rigid validation for these strings. Prefer using constants rather than manually typing action names.
- enabled: bool#
Whether or not this action config is enabled by default.
Note
This defaults to
True
since it’s assumed that most listed action configs will be enabled and used by default. This is the opposite of Bazel’s native default.
- tools: List[label]#
The
pw_cc_tool
to use for the specified actions.If multiple tools are specified, the first tool that has
with_features
that satisfy the currently enabled feature set is used.
- flag_sets: List[label]#
Labels that point to
pw_cc_flag_set
s that are unconditionally bound to the specified actions.Note
The flags in the
pw_cc_flag_set
are only bound to matching action names. If an action is listed in this rule’spw_cc_action_config.action_names
, but is NOT listed in thepw_cc_flag_set
'spw_cc_flag_set.actions
, the flag will not be applied to that action.
- implies: List[str]#
Names of features that should be automatically enabled when this tool is used.
Note
If this action config implies an unknown feature, this action config will silently be disabled. This behavior is native to Bazel itself, and there’s no way to detect this and emit an error instead. For this reason, be very cautious when listing implied features!