Stop exporting language modules

[comius]

No description provided.

[Wyverald]

just FYI, this won't work with Bzlmod. The module rules_android won't have the repo name rules_android, but something like rules_android~1.2.3.

[comius]

Thanks! Very helpful!

[brentleyjones]

After this, how does one call cc_common.merge_cc_infos or cc_common.get_memory_inefficient_command_line (methods that my ruleset for Xcode IDE integration depends on, as well as Tulsi depends on)?

[comius]

After this, how does one call cc_common.merge_cc_infos or cc_common.get_memory_inefficient_command_line (methods that my ruleset for Xcode IDE integration depends on, as well as Tulsi depends on)?

Via load("@rules_cc/cc:defs.bzl", "cc_common"). I just noticed my PR didn't get properly exported into rules_cc :(

[brentleyjones]

Ahh, I didn't see that rules_cc was being revived. Thanks!

Does rules_cc have all of the changes to the crosstool/toolchain that have been made to Bazel recently? I recall that when people used rules_cc in the past they would get old macOS crosstool/toolchain behaviors, and we've been recommending they remove the use: envoyproxy/envoy#19760.

[comius]

Ahh, I didn't see that rules_cc was being revived. Thanks!

I've unclogged the pipelines!
https://github.com/bazelbuild/rules_cc/blob/main/cc/defs.bzl#L178

Does rules_cc have all of the changes to the crosstool/toolchain that have been made to Bazel recently? I recall that when people used rules_cc in the past they would get old macOS crosstool/toolchain behaviors, and we've been recommending they remove the use: envoyproxy/envoy#19760.

I don't know... feel free to push the changes...

[brentleyjones]

I don't know... feel free to push the changes...

cc: @keith

Will rules_cc become the canonical location? The issue we had before was it was hard to keep both up to date (going through review on both, dealing with versioning issues, etc).

[comius]

Will rules_cc become the canonical location? The issue we had before was it was hard to keep both up to date (going through review on both, dealing with versioning issues, etc).

It will, however that will take time.

The first thing that's coming is ProtoInfo, JavaInfo and CcInfo in Starlark (most likely in this order). I tried different migration paths, and the easiest migration from "builtin Starlark code" to "pure Starlark code in repos" seems to be first force users to use @rules_proto, @rules_java and @rules_cc. It makes it possible to have some deps on providers still in Bazel.