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
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
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
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
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
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
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
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
