select should support platform

[xiedeacc]

Description of the feature request:

I defined mutil platform for different cross-compile, I need pass different config value to configure, but select think paltform is a invalid condition, I have to use select with and condition and specify these condition on comand line, it's so ugly, I think select support platform is a better and beautiful way

What is the output of bazel info release?

5.1.1

[katre]

Can you please give a code sample of the syntax that you want to have supported? We do support using constraint_value targets in select, but this is limited to a single one, or you can use config_setting to group several related constraint values.

If you're asking about using the label of a platform directly in a select, see my recent response on #14604 about why that's difficult and not something we'll support soon.

Possibly I should make that answer part of the select FAQ.

[xiedeacc]

@katre I'm asking using label of a platform directly in select, I think you should support this feature not matter how difficulty, otherwise it's too ugly to use selects.config_setting_group instead

[katre]

As I told @cpsauer, I will be happy to see a proposal for adding this feature that can deal with ambiguities and reduces user confusion, but we're not going to be able to prioritize that on the Bazel Configurability team.

[xiedeacc]

As I told @cpsauer, I will be happy to see a proposal for adding this feature that can deal with ambiguities and reduces user confusion, but we're not going to be able to prioritize that on the Bazel Configurability team.

ok, hope you'll support it in the future, thanks

[pcjanzen]

too ugly to use selects.config_setting_group

if your use case is exactly matching a platform, you can already do

config_setting(
    name = "is_my_platform",
    values = {
        "platforms": "//platforms:my_platform",
    },
)

[cpsauer]

Ah man, John (and @gregestren, since he seems to be interested, too--hope that's okay), you're sure not supporting this is the right move long term?

Totally understand if you don't have bandwidth right now. And I definitely don't want to irritate you guys. (I really appreciate you!)

It just does earnestly seem to this user that the ambiguity you're referencing might cleanly resolve in favor of the same behavior as the equivalent constraint_setting()--with the other exact-match option eliminated for the same good reasons as at the end of your PR. (Same sentiments in my prior response to yours that you'd linked, but which I think you haven't seen yet based on context.)

Obviously if you still disagree, I'll happily shush. For sure your call (not mine). Just an interested user who cares maybe a little too much.

Cheers,
Chris

[katre]

I'm willing to support the feature, but I don't have free time to write up a full proposal and make sure the semantics make sense. If someone else (hint, hint) wants to do that, I'll commit to review it and work with the author on implementation.

[katre]

Closing for now, but as I said I'm receptive to proposals in this space.

[cpsauer]

Hints certainly received! :) Sounds like more open to it than I'd realized.

That said, I'm not going to implement this one or work through a more formal process. You all have a big advantage here over me on design and implementation, being immersed in this stuff, and I should focus my contributions elsewhere.

[Already working way hard trying to help make editing bazel codebases a great experience across editors and there's a lot more I can do there easily, contributing a fair amount to Bazel itself--and I've got a startup I need to make succeed.]

Anyway, cheers, all! And go Bazel and Team Configurability. You guys are awesome.