Expose main_output on cc_common.link

[keith]

This field is useful for many situations, such as when you want to create a native python extension, which doesn't follow the standard library naming conventions.

[keith]

I didn't notice anything in the code about issues that need to be solved before this makes sense to be public, so I was hoping this PR could serve as the discussion point for that, cc @comius

[comius]

There's a lot of tech debt around this code, so I wouldn't expose it. It's mostly related to Apple and Android rules.

There's a design doc about the ideal end state: https://docs.google.com/document/d/1zm1UOftT2xHQiNNxNO7XU_BOn2KrXjFlx5tl4QBVjV0/edit#heading=h.5mcn15i0e1ch

I have an idea how to makes things nicer even without it, but I'll only be able to do it once Starlark cc_common.link lands. Currently link is feature complete, passing Hyrum depo-wide testing, but it has a large regression, which I just didn't have time to look into.

[keith]

thanks for the context. AFAICT in the open source world, rules_apple doesn't ever use main_output https://github.com/bazelbuild/rules_apple/blob/b4a1d1e71ee655ff6d6b51b5845757377febf321/apple/internal/linking_support.bzl#L430-L439 and neither does rules_swift https://github.com/bazelbuild/rules_swift/blob/1aec64c218fc057c2a836e67bd55bc514e0ef8bb/swift/internal/linking.bzl#L612-L624

This must have diverged internally? (even the upstream branches don't use these either)

Also worth noting that it looks like internally google has solved the python case that I am trying to solve using this API https://github.com/bazelbuild/bazel/blob/99434b16ba41677b92f7eb79d5d8dcb1130d7c47/src/main/starlark/builtins_bzl/common/python/py_executable.bzl#L518, but externally this code is a no-op https://github.com/bazelbuild/bazel/blob/99434b16ba41677b92f7eb79d5d8dcb1130d7c47/src/main/starlark/builtins_bzl/common/python/py_executable.bzl#L472-L473

[keith]

@comius since it's been a while has there been any movement on your end around this stuff?

Looks to me like rules_python is still relying on these private APIs for the same reason, and now they're exposed through a new python specific shim for that reasons https://github.com/bazel-contrib/rules_python/commit/6607a4ae4f680af879a0148e95a7ea78eca9dafa#diff-c93321fbbb76c6d72593e7c24e6b7d460e7a92dace1a7fd73123232e7a590bc0R525-R529

I still have this case internally but also have a new case where rules_mojo would like to provide a mojo_shared_library rule (ideally not a macro wrapping a cc_shared_library), and in order to support creating python extensions we also need this behavior. I imagine the same is true for rules_go and rules_rust but I guess not enough folks are creating native python extensions for them to have hit that case yet.

For other folks hitting this issue you can workaround the private API checks like this:

def _foo(rctx):
    rctx.file("BUILD.bazel", "")
    rctx.file("foo.bzl", """\
def link(**kwargs):
    return cc_common.link(**kwargs)
""")

foo = repository_rule(
    implementation = _foo,
)

# MODULE.bazel
foo = use_repo_rule("//:foo.bzl", "foo")

foo(name = "build_bazel_rules_android")