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.