Conversation
This makes it easier to compose action sets that are very similar to other ones but excluding a few things. This is used today for lto_backend, and in this change is also used for header parsing, which produces a warning when `-c` is passed.
keith
requested review from
c-mita,
hvadehra,
pzembrod and
trybka
as code owners
| ) | ||
|
|
||
| cc_action_type_set( | ||
| name = "compile_actions_without_header_parsing", |
There was a problem hiding this comment.
This seems a little overkill since we can just do this:
cc_action_type_set(
name = "source_compile_actions",
actions = [
":compile_actions_without_header_parsing",
":cpp_header_parsing",
],
)I'm not convinced the set of actions is unruly enough to justify extending the API, but it's possible there are more complex usages that could justify it.
I'd prefer for the case of fixing this bug we keep the solution simple.
There was a problem hiding this comment.
Which immediately pushes the complexity further down... let me see if there's a path to cleaning this up without making a huge mess.
There was a problem hiding this comment.
i think one nice thing about the exclusion api is it's much more clear looking at a target definition like this that it's not missing anything else, where in the current source_compile_actions just looking at the definition you can't easily spot the things that are being omitted, and you also can't spot things that were accidentally left out as new actions are addedd
There was a problem hiding this comment.
Purely accumulating doesn't look too bad after a bit of cleanup: #686
I could be convinced that excludes is justified if there are further compelling examples that live outside of rules_cc.
2 participants
This makes it easier to compose action sets that are very similar to
other ones but excluding a few things. This is used today for
lto_backend, and in this change is also used for header parsing, which
produces a warning when
-cis passed.