Cpp toolchain make variables, tool_path, and action_config

[ChewyGumball]

I use my own cc_toolchain, and, with a lot of spelunking into the default toolchain, and sometimes in to the Java source to figure out what features are needed, I have things working pretty well with one exception: Make Variables.

My toolchain uses action_configs to specify tools because it was simpler for me to have the tool binaries in a separate repo from the toolchain definition. I don't set up any tool_paths because they seemed unnecessary (even deprecated, though its not explicitly stated so) if I have action_configs set. Unfortunately for me, c++ toolchain make variables ($(CC), $(AR), etc) are set based on tool_paths only, so they are still needed, even if you have action_configs.

It seems like these make variables aren't widely used, as it has taken almost a year of using my toolchain before I even realized it was an issue. Specifically, I tried to depend on openssl, which uses $(CC). I won't go into the details of why it does, but it seems reasonable for it to do so after some investigation. It looks like make variables are set in the internal starlark code here. This function is called in a situation that can access cc_common.get_tool_for_action.

I can change my setup to have the tools in the same package as the toolchain to allow tool_paths to work, however I would prefer that the make variables work with action_configs so I have two questions that I think are worth discussing:

1. Is the use of tool_path instead of action_config to set make variables an intentional choice, or is it just a forgotten, esoteric corner of a cc_toolchain that wasn't updated?
2. Would making it use action_config tools instead of tool_paths be as straightforward as updating the starlark code to use cc_common.get_tool_for_action or are there some subtle differences, or situations where something more complicated is needed?

[ChewyGumball]

I did a little testing locally, and it looks like adding something like the following to cc_helper.bzl works for my use cases.

    if cc_common.action_is_enabled(feature_configuration = feature_configuration, action_name = ACTION_NAMES.c_compile):
        result["CC"] = cc_common.get_tool_for_action(feature_configuration = feature_configuration, action_name = ACTION_NAMES.c_compile)

    if cc_common.action_is_enabled(feature_configuration = feature_configuration, action_name = ACTION_NAMES.assemble):
        result["AR"] = cc_common.get_tool_for_action(feature_configuration = feature_configuration, action_name = ACTION_NAMES.assemble)

    if cc_common.action_is_enabled(feature_configuration = feature_configuration, action_name = ACTION_NAMES.cpp_link_dynamic_library):
        result["LD"] = cc_common.get_tool_for_action(feature_configuration = feature_configuration, action_name = ACTION_NAMES.cpp_link_dynamic_library)

    if cc_common.action_is_enabled(feature_configuration = feature_configuration, action_name = ACTION_NAMES.strip):
        result["STRIP"] = cc_common.get_tool_for_action(feature_configuration = feature_configuration, action_name = ACTION_NAMES.strip)

The openssl bzlmod dependency now compiles happily with my toolchain, and I have the binaries coming from a different module than the toolchain is defined.

My questions still remain, though, as my singular test case doesn't feel sufficient to provide an answer.