BEGIN_PUBLIC
Update toolchain variable definitions to allow static linking
Updates the rules-based-toolchain variable definitions to reflect the how the variables are used in Bazel's CppActionConfigs.java Java implementation, particularly with respect to static linking.
END_PUBLIC
PiperOrigin-RevId: 647301605
Change-Id: I7ff87a75f9654d70ea160282ba66e99363c79ce5
BEGIN_PUBLIC
Makes the `args` attribute of `cc_feature` optional so that users may declare sentinel features that do not have any inherent arguments.
END_PUBLIC
PiperOrigin-RevId: 646545838
Change-Id: I470a496aec951608f21cc8ea693387c5b551c8a9
BEGIN_PUBLIC
Remove the "data" attribute from cc_action_type_config.
Technically speaking, data shouldn't be associated with action types. Instead, data should be associated with either a tool or a set of flags.
For example, instead of the cc_compile action having the header files as a data dependency, the "include_paths" cc_arg should instead declare `data = <header files>`.
This will allow us to, once we have a fully starlark-ified c++ toolchain, do much finer-grained dependencies. This will allow us to, for example, not provide header files to the action when the user enables the feature "nostdlib".
END_PUBLIC
PiperOrigin-RevId: 642434412
Change-Id: Id16fe05a1c86bbaf4718cd36a15f8a9d6afb0163
BEGIN_PUBLIC
Make output_file accessible from strip.
See https://github.com/bazelbuild/bazel/pull/22638
END_PUBLIC
PiperOrigin-RevId: 640622335
Change-Id: I96fdca9494e5043f546b588490d692d67f94ee2b
BEGIN_PUBLIC
Remove legacy toolchain flags.
This will allow us to enforce that users of the rule based toolchain are not using legacy toolchain resolution, and simplify toolchain creation.
END_PUBLIC
PiperOrigin-RevId: 640017209
Change-Id: I6ea4fad8ddf1a06ad17d706d82e54eb7f05aa6c6
BEGIN_PUBLIC
Create a cc_directory_tool rule.
This should allow for easy definition of tools from the sysroot. For example:
cc_directory_tool(
name = "clang",
directory = "@sysroot//:sysroot",
executable = "usr/bin/clang",
)
END_PUBLIC
PiperOrigin-RevId: 639947945
Change-Id: I4c211eb9c0b5fdc6457d9d32ef9250b5384a4ef3
BEGIN_PUBLIC
Make toolchains use directory markers instead of strings.
You now refer to this instead of a string containing the repo mapped path.
END_PUBLIC
PiperOrigin-RevId: 639946886
Change-Id: I409be7b7002252b06562a2982a2568e79811877d
BEGIN_PUBLIC
Doing a transition to the exec platform in rule-based toolchains was causing unusual behaviors when attempting to restrict compatibility. This changes most of the toolchain rules to be evaluated from the target platform configuration, only transitioning to the exec configuration when explicitly requested.
END_PUBLIC
PiperOrigin-RevId: 634411095
Change-Id: I8716b9a517d9f3be306cdf96dafb98a868a3f83b
BEGIN_PUBLIC
In create_cc_toolchain_config_info, the target_system_name, target_cpu, and target_libc attributes are documented as required and deprecated. In practice, these may safely be `None`. This updates the cc_toolchain rule implementation to no longer require that these attributes are set to arbitrary values.
END_PUBLIC
PiperOrigin-RevId: 633149160
Change-Id: Ief1d3236ead9299b307ce9ace68cd295536a7b3b
BEGIN_PUBLIC
Implement flag_group in the new rule-based toolchain.
END_PUBLIC
PiperOrigin-RevId: 622107179
Change-Id: I9e1971e279f313ce85537c899bcf80860616f8b7
BEGIN_PUBLIC
Fix the load broken by a new version of buildifier.
Apparently the native-cc lint has been split into native-cc and native-cc-proto. This meant that our native.cc_proto_library was getting incorrectly turned into cc_proto_library when copybara invoked buildifier.
END_PUBLIC
PiperOrigin-RevId: 622097522
Change-Id: Idb89a5f9facae20f490ac8f83a5adf2859cd52ab
BEGIN_PUBLIC
Gather variable metadata for the new rule-based toolchain.
END_PUBLIC
PiperOrigin-RevId: 622000877
Change-Id: I5b2ea6c363fc43fd44e60ffc8fa7ae041545337e
BEGIN_PUBLIC
Improve errors in variable definitions by adding labels to the variables.
END_PUBLIC
PiperOrigin-RevId: 618984216
Change-Id: I5d6d11ba2b72f426b9f01bcbb528b0914c98c964
BEGIN_PUBLIC
Refactor action sets for consistency and simplicity
* Remove the "CC" prefix on some of the actions, as we're already within the scope of rules_cc.
* Remove the "all" prefix, since the plural "actions" should already imply this.
* Ensure all action types sets end with "_actions"
* Refactor some action type sets to be constructed from other (eg. link actions = link executables + link dynamic libraries).
* Remove the redundant "all_compile_actions", since it was equivalent to "all_cc_compile_actions"
END_PUBLIC
PiperOrigin-RevId: 617985242
Change-Id: I9a3621a9d613ff604efdc5c86ba52e5c77f06731
BEGIN_PUBLIC
Add strictly typed variables to toolchain rules.
This should allow us to implement a proper replacement for flag_group
END_PUBLIC
PiperOrigin-RevId: 617338607
Change-Id: I7f3058578cb5eb17ecc1aa38d2e1459e0742aee9
After discussion with @amontanez in unknown commit, we decided that NestedArgs was a more appropriate name.
BEGIN_PUBLIC
Rename ExpandArgs to NestedArgs
END_PUBLIC
PiperOrigin-RevId: 617085672
Change-Id: I1d7190cac79f8fa953d23be7d0db3b028a84cf30
BEGIN_PUBLIC
Refactor AddArgsInfo into ExpandArgsInfo
This allows us to create a similar mechanism to the current toolchain, while maintaining type safety.
END_PUBLIC
PiperOrigin-RevId: 615939056
Change-Id: I9b6763150194f8a76dfd8da730a3e2d45accbe20
Fix problem with the toolchain definition.
A test for this will be added later in the form of an example toolchain.
END_PUBLIC
PiperOrigin-RevId: 615416990
Change-Id: I1f7fd1640e88b446597768b4f75c2154b630074f
BEGIN_PUBLIC
Rename additional_files to data.
This is more consistent with other rules.
END_PUBLIC
PiperOrigin-RevId: 615364332
Change-Id: Ic27ec8c8e72d290e72074034f85a34b38401599b
BEGIN_PUBLIC
Implement the cc_toolchain macro.
Things should be working at this point. This will be followed up with an example.
END_PUBLIC
PiperOrigin-RevId: 613436885
Change-Id: I1fc4a1e3a71c4f819998b69c73922821322d2991
BEGIN_PUBLIC
Allow cc_toolchain_info rule to be used as a parameter to pass into native.cc_toolchain(config = ...)
END_PUBLIC
PiperOrigin-RevId: 613000772
Change-Id: I8348e2cbb4aa7d0a523341dcaf1e2c2bc647f640
BEGIN_PUBLIC
Implement cc_toolchain_config rule and cc_legacy_file_group rule.
Note that this rule is in the impl/ directory because we require users to use the cc_toolchain_config rule via the cc_toolchain macro that we will define later, to ensure that parameters such as `compile_files` are passed correctly.
END_PUBLIC
PiperOrigin-RevId: 612998387
Change-Id: I986d11775e368c4386a930ab2ce8663956a57f9d
Implement ToolchainConfigInfo.
Add support to create the toolchain from feature, action config, and args targets, and validate it to ensure correctness.
END_PUBLIC
PiperOrigin-RevId: 612985448
Change-Id: I7d9086dd1dde07eb0c2484414c9c28c1b8bfb427
Based on the comments in unknown commit, I created this CL
BEGIN_PUBLIC
Remove macros wrapping rules that take in features.
END_PUBLIC
PiperOrigin-RevId: 612979047
Change-Id: I5690717b164432c9cecebf87ef9dda41f9fa846f
Implement builtin CC toolchain features.
This will allow you to override builtin features
END_PUBLIC
PiperOrigin-RevId: 610887686
Change-Id: I30e928c116386ec703dff24a97f925481c395b06
Implement cc_action_type_config.
Rename it from cc_action_config, to make it clear that we are not configuring an action, but rather configuring a type of action.
END_PUBLIC
PiperOrigin-RevId: 610518142
Change-Id: Ic10755952ee786d30a3a5564aa09a8dc16499f3a
Implement cc_args_list.
It's completely unneccesary to implement it this early, but collecting args lists is also required for cc_feature.
END_PUBLIC
PiperOrigin-RevId: 609833962
Change-Id: I369a929af4280c0a7ebbe2e13159b640c1968209
Pull more info into ArgsListInfo.
This allows us to make queries such as "get me all the flags / files required for this specific action". This will allow us to implement cc_action_config more easily and efficiently.
END_PUBLIC
PiperOrigin-RevId: 609828504
Change-Id: Ie3978674c5027f892d2e5e4c8d937a52c59fde5d
Implement cc_args.
Also change cc_flag_set / cc_flag_group to cc_args / cc_arg_group. This is to lean into the idea that this is roughly equivalent to ctx.actions.args()
END_PUBLIC
PiperOrigin-RevId: 608804069
Change-Id: I74ea883b14219f904aaafc4eab902b96a1fb3e3d
Add support for testing rules_cc's new toolchains with rules_testing.
END_PUBLIC
PiperOrigin-RevId: 608769646
Change-Id: I1a698355e5e977cc86eedc7cf6e8e0f888593cb8
Similar to the previous CL, this CL is to ensure that we agree on the relationship between each different type.
This will also allow for developing two things in parallel:
* The rules that generate these providers.
* Toolchain validation, and conversion to the cc_toolchain_config_lib providers.
PiperOrigin-RevId: 606391257
Change-Id: I9c2a9895d71ed987e85eb60f908d9833b838d9f8
As of Bazel 6.0.0, all Bazel-provided toolchains report consistent
compiler names that can be matched on with `select`. Having a central
place for `config_setting`s that can be used for this purpose makes it
so that rulesets don't have to define them themselves and moving the
compiler flag out of `@bazel_tools` becomes easier as it is no longer
referenced directly.
Also includes minor fixes to `//tests/...` so that it can be enabled in
CI.
Right now there should be no difference between `cc_host_toolchain_alias` and `cc_toolchain_alias` rules.
This is a potentially breaking change for Bazel, if something was depending on `current_cc_host_toolchain` try depending on `current_cc_toolchain` instead.
PiperOrigin-RevId: 528762965
Change-Id: Id2d211c61fa06a578a838c054682c3507aa48261
Remove redundant tags for copybara to replace labels with labels including the
repository, where there are no labels to substitute after 2f8c04c044.
PiperOrigin-RevId: 510103824
Change-Id: I9b65a6b7f9b48885aec4df5f4723273633be4860
Numerous tools override --custom_malloc to add debugging or monitoring runtimes
(see e.g. sanitizers). While this is fine for cases where the tool must also
override malloc to function, in other cases it's simply misuse of
--custom_malloc where no other mechanism exists to link an extra library.
This becomes especially problematic where a runtime library is supposed to be
added in certain configurations that should run in production or other
performance sensitive builds. In these cases, we should _not_ override malloc,
which may also be specified by a cc_binary target. Doing so would introduce
unwanted changes, potentially affecting performance negatively.
This is the @rules_cc counterpart to the equivalent Bazel tools flag
--@bazel_tools//tools/cpp:link_extra_libs. Users that use @rules_cc to build
their C++ projects may use both flags interchangably, however, the @rules_cc
flag should be preferred.
PiperOrigin-RevId: 510103352
Change-Id: Iafccd00ffdb65cb4f953d5acadc451cffc134533
BEGIN_PUBLIC
Copybara import of the project:
--
56e69b82484f1a9fb55d8173cc112f9f608f3581 by Fabian Meumertzheim <fabian@meumertzhe.im>:
Simplify WORKSPACE setup and update ancient deps
By removing a single unused `bzl_library` target, rules_cc no longer has
any dependencies that would need to be loaded by a dependency macro. The
existing macro is made a no-op.
The few needed Bazel Federation dependencies are inlined and, in the
case of bazel_skylib and abseil-py, updated to modern versions.
Also reorders `WORKSPACE` to list direct dependencies first and keeps
`MODULE.bazel` in sync with the dependency versions used in WORKSPACE.
The `ubuntu1604` CI pipeline is removed as the version of Python used by
it is no longer supported and the distribution is EOL. Instead, a new
pipeline is added to check the Bzlmod build.
END_PUBLIC
COPYBARA_INTEGRATE_REVIEW=https://github.com/bazelbuild/rules_cc/pull/165 from fmeum:fix-workspace-module 56e69b82484f1a9fb55d8173cc112f9f608f3581
PiperOrigin-RevId: 501245864
Change-Id: Ib71ad910705807a00929a76774387a38d2da0f9f
*** Reason for rollback ***
Broke a test
*** Original change description ***
The auto-configured toolchains provided by Bazel itself have diverged heavily from the version maintained in this repo. There is no need to maintain this duplication until Starlarkification has progressed succiciently for rules_cc to be the source of truth for them.
This is particularly relevant for Bzlmod, which currently uses the toolchains defined in rules_cc. As a result, Bazel C++ builds will use subtly different toolchains depending on whether --enable_bzlmod is used or not. This is fixed...
***
PiperOrigin-RevId: 501228335
Change-Id: I858dc3ea44df7ae70b5603f6dc2e082b4540c42a
This is particularly relevant for Bzlmod, which currently uses the toolchains defined in rules_cc. As a result, Bazel C++ builds will use subtly different toolchains depending on whether --enable_bzlmod is used or not. This is fixed by loading toolchain detection logic from @bazel_tools in the module extension.
Closes #163
PiperOrigin-RevId: 501199523
Change-Id: I01f263d37495d0c5dd070c8a32945898d1d639c5
The version has never been updated since the first release and since rules_cc is currently a slim wrapper around Bazel-provided rules, version detection shouldn't be necessary.
Instead, add an alias to the Bazel-provided runfiles library under //cc/runfiles, following https://bazel.build/rules/deploying.
Closes #162
PiperOrigin-RevId: 500929486
Change-Id: I3290c2b836af2313fbf45459c81af24fbde877d0
- point to bazelbuild/platforms for @platforms
- Use a newer version of rules_go for our internal rules.
- Make a bzl file used in a test visible to the tests.
I believe this fixes a build breakage in bazel at head and 5.3.0
They are now part of the bazelbuild/bazel repository.
Copies buildifier changes contributed by Keith in https://github.com/bazelbuild/rules_cc/pull/128
RELNOTES:none
PiperOrigin-RevId: 435312636
Change-Id: I4d5d2f58d90026c0cdfb5c0a90709de7c28c6ccd
- bazel presumed a trailing space in `clang-cl -v` output that is
no longer present in the 11.0.0 release, resulting in an injected newline
Co-authored-by: Sunjay Bhatia <sunjayb@vmware.com>
Co-authored-by: William A Rowe Jr <wrowe@vmware.com>
Signed-off-by: Sunjay Bhatia <sunjayb@vmware.com>
Signed-off-by: William A Rowe Jr <wrowe@vmware.com>
These are used throughout the Crosstool features definitions based on local definitions there. It seems useful to move these to a common location so they are available for other toolchains (and also so that they get updated if new actions are added to the action-name list).
The versions of these currently used by Crosstool are defined in //third_party/crosstool/v18/llvm_unstable/crosstool_helpers.bzl starting at line 124.
Tested:
by inspection
PiperOrigin-RevId: 339440647
Change-Id: I3a2b8d37aebd8a0e8450864e079cf5b42d075def
This is phase 2 of of the switch to toolchain transitions. See https://github.com/bazelbuild/bazel/issues/11584 for details.
PiperOrigin-RevId: 334808134
Change-Id: Ie198b07359d4fd45368755c4cc223e397f0e8fb0
Googler