This should make the concept of "sentinel features" work correctly with known_features and enabled_features, rather than enabling them directly in features.
PiperOrigin-RevId: 681688437
Change-Id: I29184a2079ccfd0eb3a275439508a66ca61109af
BEGIN_PUBLIC
Remove experimental_enable_rule_based_toolchains flag
Rule-based toolchains will not be gated by a flag when released with rules_cc v0.0.10. Also, this flag is unfortunately inherently incompatible with --experimental_exclude_starlark_flags_from_exec_config.
END_PUBLIC
PiperOrigin-RevId: 674072362
Change-Id: Iebda45d4daf4cec27c48296d61092dc513442911
BEGIN_PUBLIC
Fix rule-based implementation of runtime_library_search_directories
As runtime_library_search_directories was written and reorganized through review, some instances of `$ORIGIN` were unintentionally renamed to `$EXEC_ORIGIN`. This change fixes those instances to correctly mirror CppActionConfigs.java.
END_PUBLIC
BUG: 349427627
PiperOrigin-RevId: 672401255
Change-Id: Ic20f9e77eccca8bc7e7f895aeaeb44f85022df28
BEGIN_PUBLIC
Implement archiver_flags as cc_args
This is the first change in a series that will reimplement the legacy
features defined in Bazel's Java code using the new toolchain rules. These implementations are redefined as raw arguments using the new toolchain rules, which allows for the definition shared and reused across different contexts.
This first change implements archiver_flags, which is used to produce the arguments for the archiver tool used by `cc_library`.
This CL also adds a test that compares the feature implementation produced by
the new rules to the feature implementation defined in Bazel's Java
code. This should make it easier to review the final result and ensure it
is functionally equivalent to the Java implementation.
END_PUBLIC
PiperOrigin-RevId: 671403834
Change-Id: I2d4f15b49619a11995a50c86439340ea532e360e
BEGIN_PUBLIC
Add support for implicit include directories to rule-based toolchains
Reorients the `cc_toolchain.cxx_builtin_include_directories` attribute so it is expressed as an attribute on `cc_args` and `cc_tool` to signify that the tools or arguments imply include directories that Bazel's include path checker should allowlist. This moves the allowlist to the source of truth that implies these directories.
END_PUBLIC
PiperOrigin-RevId: 671393376
Change-Id: Ide8cae548783726835168adcd3f705028a1f4308
BEGIN_PUBLIC
Replace sysroot with a cc_sysroot macro.
This is part of what amontanez@ and I discussed about making C++ toolchains less "magic".
I'd like to do the same for cxx_builtin_include_directories, but that will require significantly more effort.
END_PUBLIC
PiperOrigin-RevId: 666607531
Change-Id: Ic9cfb157e892c05a9c875f240c0ed9a1048dea19
BEGIN_PUBLIC
Integrate cc_tool_map into rule-based toolchains
Integrates cc_tool_map as a new attribute of cc_toolchain, completely replacing cc_action_type_config.
END_PUBLIC
PiperOrigin-RevId: 666365739
Change-Id: Iac74a31736dad66ac3dc75b4478ab4d4d2412181
BEGIN_PUBLIC
Make enabled_features functionally equivalent to cc_feature(..., enabled=True)
This should allow you to disable an enabled feature elsewhere in the toolchain.
Fixes #233
END_PUBLIC
PiperOrigin-RevId: 666318466
Change-Id: I0b820cb2033d4ce8b141ff74dcd6516b8157c2b4
BEGIN_PUBLIC
Disallow features from specifying whether they are enabled by default or not.
Such a decision shouldn't be made by the feature, but instead by the toolchain author.
END_PUBLIC
PiperOrigin-RevId: 658621275
Change-Id: I4dae8ee1acc349a0ff6f09e6cf68e15fdc481a48
BEGIN_PUBLIC
Replace toolchain_features with known_features and enabled_features.
This should allow for the deprecation of action_type_config, as `implies` there is no longer required.
END_PUBLIC
PiperOrigin-RevId: 658620044
Change-Id: Idda9bd77edad1be1fd26d5a655e3b9084d38bca8
BEGIN_PUBLIC
Remove feature requirements from tools.
It's such a niche use case, adds a fair amount of complexity, and there are multiple alternatives available:
* Now that we're using rule based things, you should just be able to add a bazel flag and select on it in your tool definition.
* If you really want precisely that behaviour, you can make your feature add "--use-foo-tool" to the args, and make your tool a wrapper tool that reads the command-line argument, and if provided, invokes a different tool.
END_PUBLIC
PiperOrigin-RevId: 657383729
Change-Id: Idb4f3ad66dc92d48ef81a1e8875bf6d3ba215aa4
This CL is an alternative to unknown commit. I left the other CL seperately, because I wasn't 100% sure that we'd agree to this, since this is an API change.
I did it this way because I believe it's much less hacky, and it also allows us to format things that aren't variables.
BEGIN_PUBLIC
Add support for select'ing on cc_args(args=...).
This is quite tricky because the one parameter was being split into two in a macro, one of type label and the other of type string.
For example, `args = ["--foo", format_arg("--bar=%s", "//path/to:bar")]` was rewritten by the macro to `args = [json.encode(struct(format_type="raw", format="foo")), json.encode(struct(format_type="format_arg", format="--bar=%s", value=0))], variables = ["//path/to:bar"]`.
To allow it to work with selects, we need to ensure that we don't perform post-processing on the inside of the select. To solve this, we:
* Ensure that args only take strings
* Provide a seperate parameter for substitutions.
This new mechanism also has the useful property that we can now format things that are not variables. For example, I can do the following:
```
directory(name = "sysroot", ...)
cc_args(
name = "sysroot_arg",
args = ["--sysroot={sysroot}"],
format = {
":sysroot": "sysroot"
}
)
```
END_PUBLIC
PiperOrigin-RevId: 656211278
Change-Id: If83f1ea5a99090c18f2a561c51ec6d39ce9fe419
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
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
Implement flag_group in the new rule-based toolchain.
END_PUBLIC
PiperOrigin-RevId: 622107179
Change-Id: I9e1971e279f313ce85537c899bcf80860616f8b7
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
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
BEGIN_PUBLIC
Rename additional_files to data.
This is more consistent with other rules.
END_PUBLIC
PiperOrigin-RevId: 615364332
Change-Id: Ic27ec8c8e72d290e72074034f85a34b38401599b
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
Add support for testing against more complex subject types.
We can now use subjects such as subjects.result(subjects.str) for something that may return a string, or fail.
END_PUBLIC
PiperOrigin-RevId: 608971309
Change-Id: I9ae61c988a597189b84fb6ccef75c96697c6e364
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
