Per-target feature enablement?

[canada-geek]

Hi all,

My first time posting (please be gentle :-) )

I've been searching for this for a while (and querying various LLMs), hopefully you can point me in the right direction.

In our project, we have a number of code-generation tools that need to be compiled for host execution (so far so good). These tools analyze C++ files (e.g. examine their AST) as part of their work; they leverage the clang libraries that provide this functionality. We ship pre-generated source code to our customers, but at least one of these tools needs to run on customer premises with the customer-supplied compilers/libraries.

Complications arise from this:

• which clang libraries to link depends on the version of clang libraries being used for analysis
• if gcc is being used to compile the tool, some compiler flags need to be different (they are version dependent as well)
• based on customer feedback, when possible, libc++.a and libc++abi.a are linked instead of their dynamic counterparts
• these are only needed for the few targets that produce the code generators; we have other host targets that don't need (and don't want) any of this; so enabling these on the bazel command line (rendering them applicable to all targets) is not an option

I've been trying to figure out how best to express this in bazel/starlark. Here is (roughly) my thought process:

• (it seems to me that) the whole point of the platforms/toolchains architecture is to encapsulate these differences so the BUILD files don't need to know or care which compiler is being used
• I wonder then about attributes like copts and linkopts; it seems (to me) it would only work for options that are common across all possible compiler families/versions?
• maybe a neat way of compartmentalizing this would be to set it up as a "feature" in the toolchains (admittedly not the best solution, but at least it would put the compiler specifics and conditional logic closer to "the right place")
• but features cannot be enabled per-target, at least not for builtin rules like cc_binary; you end up exposing compiler family/version selection into config settings or elsewhere in order to achieve this
• some have suggested I create a custom rule that somehow adjusts the features; my first reaction is to cringe at that....I've had a look at the rules_cc implementation; curating a(n augmented) clone of this would be a maintainability nightmare (we'd much rather leverage the great work done there by others)
• what about these parent/child custom rules? Might this be an avenue by which I can manipulate the enabled features before invoking the child rule (in this case, cc_binary)? I seem to recall reading somewhere that this hierarchical rule mechanism is not available for builtin rules (yet?)

I'd appreciate your input on:

• helping me understand the design intent behind these pieces
• how best to address the requirements for these targets
• hopefully how to avoid making a right mess of things in BUILD (or bzl) files

Thanks for your time and attention.

EDIT: fixed a few typos.

[canada-geek]

Friendly ping... any insight anyone?

[sluongng]

I think your analysis is mostly there. I think you would want to model it like this

• Create fine-grained constraint_setting and constraint_value.
• Create a default set of platform+toolchain matching the basic constraint_value.
• For each customer, you can use override_module to swap out the platform+toolchain pair for something else without customers being aware of each other. They are still exposed to all the constraints inside the main repo though.
• Build targets should make heavy use of {target,exec}_compatible_with against the constraint_value, this replaces your needs to enable/disable features per-target.

From there, there are several ways for you to change the build configuration:

• Enable/disable features in toolchain definition
• You can use https://bazel.build/concepts/platforms#platform-mappings to change up flags based on platforms.

[gregestren]

Nice analysis, @sluongng .

I'd consider platform-based flags over platform mappings. They're functionally the same but platform-based flags is a principled way to auto-set flags for a platform. Platform mappings is a bridge API to support migrating from modeling platforms with --cpu, --crosstool_top, etc. to --platforms. We want to remove platform mappings when possible.

There's also an emerging feature called PROJECT.scl that makes it possible to automatically set the right build flags for the right targets. So $ bazel build //foo "just works", automatically, with the right flags. This supports per-target settings. But it's a new feature, on the cutting edge. See #24839 and examples here and here.