cc_binary can't be passed to inherit_attrs

[isus-ipanienko]

I want to wrap cc_binary in macros to select a different compiler for multiple binaries. I came up with this which works perfectly with native cc_binary.

def _wrap_impl(name, **kwargs):
    cc_binary(
        name = name,
        **kwargs,
    )

    _transition_to_clang(
        name = name + "_transition",
        binary = name,
    )

cc_wrap = macro(
    inherit_attrs = native.cc_binary,
    implementation = _wrap_impl,
)

When I change native.cc_binary to cc_binary from rules_cc, I get an error since the latter is exported as a function instead of a rule, contrary to what the cc_binary docstring in rules_cc/cc/cc_binary.bzl states.

[isus-ipanienko]

I omitted the implementation of _transition_to_clang since it's irrelevant to the issue.

[ivwumupy]

I'm encountering with this too. Any way to work around?

[isus-ipanienko]

I just used native.cc_binary. Another way is to create a regular starlark function (just import _wrap_impl directly), but this way you get worse error messages. I don't see any other way currently.

[keith]

use load("@cc_compatibility_proxy//:proxy.bzl", _upstream_cc_binary = "cc_binary")

[carpenterjc]

We used to use native.binary workaround however while testing bazel 9.0 that no longer works.
load("@cc_compatibility_proxy//:proxy.bzl", _upstream_cc_binary = "cc_binary") does work, you also need to add this:

cc_compatibility_proxy = use_extension("@rules_cc//cc:extensions.bzl", "compatibility_proxy")
use_repo(cc_compatibility_proxy, "cc_compatibility_proxy")

to your MODULE.bazel

[canada-geek]

How long will this proxy be supported? Is this just an interim workaround while we transition to pure-Starlark for rules_cc?

I'm also curious as to why cc_binary() (and the other cc_ functions) are not themselves implemented as symbolic macros (from which AFAIK we can inherit attributes)? It would be much more scalable (and maintainable) for rules_cc to curate the attribute list on symbolic macros rather than delegate that to all clients.

[canada-geek]

Also... if we use the proxy, must it replace/supercede all occurrences of cc_...() function use (including inherit_attrs and target materialization), or should the proxy only be used for attribute inheritance (and mix-and-match is supported)?