BEGIN_PUBLIC
Document feature-related toolchain rules
Extends the toolchain API documentation to cover all feature-related rules.
END_PUBLIC
PiperOrigin-RevId: 681476538
Change-Id: Icfe35e03937bdb0bc55eae24f57eafe0db7b16eb
BEGIN_PUBLIC
Add cc_action_type and cc_tool documentation
Extends the toolchain API documentation to include docs for cc_action_type, cc_action_type_set, cc_variable, and cc_tool.
Also improves cross-reference links and copybara behavior for docs.
END_PUBLIC
PiperOrigin-RevId: 680601617
Change-Id: Idbbdfbcb2c5a1c3598b6a7e7ba985ed14f871099
The majority of the time objc_compile is identical to C/C++ compiles.
Because of this I think by default all of those flags should apply here.
This is a bit funny since the current builtin toolchain doesn't support
Objective-C at all and that's only in the apple_support toolchain, but
new toolchains using these rules may want to support this.
Without this things like `--objccopt` just don't work out of the box.
BEGIN_PUBLIC
Add `@rules_cc` to generated docs
Ensures when docs are generated that the `@rules_cc` prefix is used for anything that appears to come from the repo.
END_PUBLIC
PiperOrigin-RevId: 677883741
Change-Id: I82b910b338aea8b14ecb7b192b5f3d3907be30ee
It's possible for there to be some arguments that are naturally
associated with the sysroot flag, for example on macOS there are
associated framework search paths that should be added with
`-F{sysroot}/Library/Frameworks`. There are also warnings flags you
might want to add such as `-Werror=missing-sysroot`. In this case I
think it's nicer to provide them alongside the sysroot definition,
instead of having to create a custom cc_args for them.
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
Consolidate action labels in toolchain args
Consolidates action labels used by re-implementation of legacy features to use logical groups rather than individually listing every action. This simplifies the rule definitions slightly.
END_PUBLIC
PiperOrigin-RevId: 673920103
Change-Id: If5453dd5b45d5549ff75d656da8a2873232117ae
BEGIN_PUBLIC
Create group for c compile actions
Adds `c_compile_actions` group to provide a logical C equivalent for `cpp_compile_actions`.
END_PUBLIC
PiperOrigin-RevId: 673408772
Change-Id: Ic5ccb57bc1fa7a98999d944316b97a39aac571ac
BEGIN_PUBLIC
Copybara import of the project:
--
2803a12428 by Ivo List <ilist@google.com>:
Prepare for release 0.0.10-rc2
--
3423c73208 by Ivo List <ilist@google.com>:
Format WORKSPACE
--
a99403a6b0 by Ivo List <ilist@google.com>:
Touch module
--
258d8c9f24 by Ivo List <ilist@google.com>:
Revert "Touch module"
This reverts commit a99403a6b0.
END_PUBLIC
COPYBARA_INTEGRATE_REVIEW=https://github.com/bazelbuild/rules_cc/pull/238 from comius:release-0.0.10-rc2 258d8c9f24
PiperOrigin-RevId: 673358956
Change-Id: Iabc9c29e6f168cfdfd2f0657438b71654f470cc9
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
*** Reason for rollback ***
Rollforward with fix for b/365154741
*** Original change description ***
Automated rollback of commit 0bc1ba56ef.
*** Reason for rollback ***
TAP failures in Bazel/Blaze, see b/365154741 and discussion at https://chat.google.com/room/AAAAXE3XKrY/_e3TpBFJvus
*** Original change description ***
Add user-facing documentation for cc_tool_map
BEGIN_PUBLIC
Add user-facing documentation for cc_tool_map
Adds user-facing documentation for the cc_tool_map toolchain rule, including an example and higher level analogies.
END_PUBLIC
***
***
PiperOrigin-RevId: 672000172
Change-Id: If7ad64e2378a2016d389a3718944aa04bc5e9759
*** Reason for rollback ***
TAP failures in Bazel/Blaze, see b/365154741 and discussion at https://chat.google.com/room/AAAAXE3XKrY/_e3TpBFJvus
*** Original change description ***
Add user-facing documentation for cc_tool_map
BEGIN_PUBLIC
Add user-facing documentation for cc_tool_map
Adds user-facing documentation for the cc_tool_map toolchain rule, including an example and higher level analogies.
END_PUBLIC
***
PiperOrigin-RevId: 671898382
Change-Id: Iead81a71adb17dff46b1b442471e595769fb5c2e
BEGIN_PUBLIC
Add user-facing documentation for cc_tool_map
Adds user-facing documentation for the cc_tool_map toolchain rule, including an example and higher level analogies.
END_PUBLIC
PiperOrigin-RevId: 671777889
Change-Id: Ib53de76f355db43a9530f7cbe11face3c9219675
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
Fix action label evaluation in cc_sysroot
Explicitly converts action labels in cc_sysroot to Label objects to address issues where the labels were being evaluated as relative to the module instantiating cc_sysroot rules.
END_PUBLIC
PiperOrigin-RevId: 667520654
Change-Id: Ia64306cc172dfaa747ef28a92390bcd90296b109
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
