Allow cc_toolchain to be defined across multiple repositories

[nathaniel-brough]

Description of the problem / feature request:

Currently the workflow to define a cc_toolchain is a good fit for a monorepo. However it is difficult to have a toolchain configuration span across multiple repos.

Why would I like to be able to have a toolchain span multiple repos?
I would like to share a configurable toolchain as an open source project. Therefore I would like to be able to download and use a "CcToolchainConfigInfo" provider rule from an external repository (e.g. using http_archive).

Feature requests: what underlying problem are you trying to solve with this feature?

To my knowledge this is not currently possible to span a toolchain config across multiple repositories. This is due to the fact that tool_path from "@bazel_tools//tools/cpp:cc_toolchain_config_lib.bzl" is relative to the package directory. The problem with this is that when you load a toolchain config rule from an external repository the relative paths are relative to where the rule is instantiated rather than where the rule is defined.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Follow the tutorial on configuring c++ toolchains. Then attempt to load and use cc_toolchain_config from a different workspace. Doing so will result in an error where the given toolpath cannot be found.

What operating system are you running Bazel on?

Manjaro Linux Rolling Release

What's the output of bazel info release?

release 0.23.0

If bazel info release returns "development version" or "(@Non-Git)", tell us how you built Bazel.

N/A

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

N/A

Have you found anything relevant by searching the web?

I have found that repository rules are a potential workaround. This works by passing through the attrs from the repository_rule through to a toolchain config rule. This bypasses the problem of relative paths by instantiating the config rule in the given repository. For our particular use case this is a fairly heavy weight solution as it involves creating a new repository for each of our targets. We currently have about 10 different configurations for different cc_toolchain rules, as we target a number of different embedded devices.

Any other information, logs, or outputs that you want to share?

I think that a potential solution would be to include a new rule that can reference a target rather than a relative path. e.g.

@toolchain_workspace//:BUILD

sh_binary(
    name = "gcc",
    srcs = ["gcc_wrapper.sh"],
)

@toolchain_workspace//:cc_toolchain_config.bzl

def _impl(ctx):
    tool_paths = [
        # Create a new toolchain target rule 
        tool_target(
            name = "gcc",
            target = ctx.attr._gcc_executable,
        ),
    # Truncated
    ]
    return cc_common.create_cc_toolchain_config_info(
        ctx = ctx,
        # Truncated
        tool_paths = tool_paths,
    )

cc_toolchain_config = rule(
    implementation = _impl,
    attrs = {
        "_gcc_executable" = attr.label(default="@toolchain_workspace//:gcc"),
        "foo" = attr.string(),
    },
    provides = [CcToolchainConfigInfo],
)

This should support the following usage;
//:BUILD

load("@toolchain_workspace//:cc_toolchain_config.bzl", "cc_toolchain_config")
cc_toolchain(
    name = "my_toolchain",
    toolchain_config = ":my_config",
)
cc_toolchain_config(
   name = "my_config",
   foo = "foo_param",
)

[katre]

Re-assigning to team-rules-cpp for triage: this is strictly part of the setup of cc toolchains, and doesn't impact toolchain resolution at all.