Skip to content

Change rules based toolchain macOS conditions to Apple#614

Closed
keith wants to merge 3 commits into
bazelbuild:mainfrom
keith:ks/change-rules-based-toolchain-macos-conditions-to-apple
Closed

Change rules based toolchain macOS conditions to Apple#614
keith wants to merge 3 commits into
bazelbuild:mainfrom
keith:ks/change-rules-based-toolchain-macos-conditions-to-apple

Conversation

@keith
Copy link
Copy Markdown
Member

@keith keith commented Mar 2, 2026

This allows you to write a rules based toolchain that targets Apple
platforms that aren't macOS.

I made this overridable since there are other constraints in apple_support
that denote you're building for an apple platform. But those only matter
if you're building a non-standard platform.

Fixes #370

@cerisier
Copy link
Copy Markdown
Contributor

cerisier commented Mar 2, 2026

That's great !

@keith keith force-pushed the ks/change-rules-based-toolchain-macos-conditions-to-apple branch 2 times, most recently from bf20a1f to 2bfe8a4 Compare March 6, 2026 16:14
@keith keith force-pushed the ks/change-rules-based-toolchain-macos-conditions-to-apple branch from 2bfe8a4 to 638ca4b Compare March 25, 2026 20:09
@keith keith force-pushed the ks/change-rules-based-toolchain-macos-conditions-to-apple branch from 638ca4b to 4e764a8 Compare March 25, 2026 20:13
@armandomontanez armandomontanez added P2 We'll consider working on this in future. (Assignee optional) category: toolchains type: internal cleanup Does not directly address a feature request or a bug report, but improves project hygiene labels Mar 26, 2026
@armandomontanez armandomontanez added the untriaged Team member has to triage this issue - assign priority, type, and owner (if possible). label Apr 13, 2026
Comment thread cc/settings/BUILD
label_flag(
name = "apple",
build_setting_default = ":default_apple",
visibility = ["//visibility:public"],
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, didn't catch this on my first pass:

Does this need to be public? Considering it's a flag, anyone can set it to match their own canonical definition. I'd prefer this doesn't become load-bearing. If it does, we might want to bikeshed for a moment on naming:

@rules_cc//cc/constraint:apple
@rules_cc//cc/toolchains/constraint:apple

platform doesn't seem correct to me, since that's a very distinct thing.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea very good question. I think the downside of not making it public is that downstream toolchains cannot perfectly mirror what happens in the default cc_args that read this version. realistically that's minor, but it would cause very subtly issues for the few people who would ever need to change this.

it being load bearing is annoying because actual downstream users should use apple_support's definitions for this instead, I just don't want to try to add that circular dependency here.

it's also possible that the best solution is to move this into platforms_contrib (since it's unlikely platforms itself wants this)

Copy link
Copy Markdown
Collaborator

@armandomontanez armandomontanez Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest putting it in @rules_cc/cc/settings:apple_constraint if we're going to make this public. Centralizing the configuration flags makes for a better user experience, and is consistent with existing rules_* modules.

Other rulesets have varying naming patterns for centralized settings:

Then we should pursue putting the flag and base definition in platforms_contrib, and we can just swap the label_flag with an alias eventually.

@trybka this will be setting a precedent, so flagging the discussion.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fine with me, moved it to the suggestion

@armandomontanez armandomontanez removed the untriaged Team member has to triage this issue - assign priority, type, and owner (if possible). label Apr 13, 2026
@hvadehra hvadehra removed their request for review April 14, 2026 04:28
@keith keith force-pushed the ks/change-rules-based-toolchain-macos-conditions-to-apple branch from 5283593 to f3b5225 Compare April 24, 2026 00:02
@armandomontanez armandomontanez added untriaged Team member has to triage this issue - assign priority, type, and owner (if possible). community-reviewed Reviewed by a trusted community contributor and removed untriaged Team member has to triage this issue - assign priority, type, and owner (if possible). labels Apr 24, 2026
keith added 2 commits April 30, 2026 13:55
This allows you to write a rules based toolchain that targets Apple
platforms that aren't macOS.

Fixes bazelbuild#370
@keith keith force-pushed the ks/change-rules-based-toolchain-macos-conditions-to-apple branch from f3b5225 to e9e150a Compare April 30, 2026 20:55
@copybara-service copybara-service Bot closed this in 31f137f May 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

category: toolchains community-reviewed Reviewed by a trusted community contributor P2 We'll consider working on this in future. (Assignee optional) type: internal cleanup Does not directly address a feature request or a bug report, but improves project hygiene

Projects

None yet

Development

Successfully merging this pull request may close these issues.

rules-based toolchain linker args missing support for non-macOS apple targets

4 participants