Do not retain a name string for generated module maps Copybara Import from https://github.com/bazelbuild/rules_cc/pull/789 BEGIN_PUBLIC Do not retain a name string for generated module maps (#789) Module maps generated for a target are named after the target's label. Since the generated module map file is declared by that very target, the name can be derived on demand from the file's owner label, which the `File` object already retains. The `name` field of the module map struct becomes optional, with `None` meaning "named after the label of the target that generated the module map file", and two central helpers (`get_module_map_name`, `get_module_map_label`) derive the string form and the `Label` form where needed. This fixes the round-trip bug originally addressed in https://github.com/bazelbuild/rules_cc/pull/633, but avoids the memory regression that caused it to be rolled back in b81b6e4 (because retaining `Label` objects increased memory usage overall). Deriving the name on demand retains nothing extra as the owner label is already retained by the `File` and all name materializations are transient only (such as in `map_each` callbacks). Names are now the unambiguous canonical label string, except that main repository labels drop the leading `@@` (`//pkg:lib`), keeping the traditional module name format. Special module maps (the crosstool module map, ObjC internal module maps) keep their explicitly provided names. Closes #789 END_PUBLIC Startblock: * // Put other blockers before this line to avoid churning. * has lgtm * is approved * and then * all comments are resolved * and then *[] allows unknown commit COPYBARA_INTEGRATE_REVIEW=https://github.com/bazelbuild/rules_cc/pull/789 from fmeum:module-map-label 68848659e21ef3b4d223a92dc19b4711b604b82e PiperOrigin-RevId: 964972527 Change-Id: If97a7c4491d670e825b621e80541a064ffe8769f
This repository contains C, C++, and Objective-C language support for the Bazel build system.
For this module's main reference, see the Bazel documentation.
Follow the official instructions to Install Bazel.
Add the latest release to your MODULE.bazel project file.
In a BUILD.bazel file, import and use the rules:
load("@rules_cc//cc:cc_binary.bzl", "cc_binary") cc_binary( name = "hello_world", srcs = ["hello_world.cc"], )
Build and run your C/C++ binary with one command:
$ bazel run hello_world
To build the project without running the binary, use Bazel's build subcommand:
$ bazel build hello_world
rules_cc includes an auto-configured toolchain that uses the local compiler installed on the host machine.
You can disable the autoconfigured C/C++ toolchain by adding the following Bazel flag to your project's .bazelrc file:
--repo_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1
Configuring a hermetic toolchain makes your build more deterministic. rules_cc itself does not yet offer a hermetic toolchain distribution. Other community owned and maintained projects offer hermetic C/C++ toolchains:
Bazel and rules_cc are the work of many contributors. We appreciate your help!
To contribute, please read the contribution guidelines: CONTRIBUTING.md.
Note that the rules_cc use the GitHub issue tracker for bug reports and feature requests only. For asking questions see:
rules_cc mailing list#cc on slack.bazel.build