Create compatibility.bzl

[trybka]

No description provided.

[trybka]

The "verbose" operators all use a named incompatible target, which means you get error messages like this:

bazel test //base:port_test --cpu=armv7a

(10:25:47) ERROR: Target //base:port_test is incompatible and cannot be built, but was explicitly requested.
Dependency chain:
    //base:port_test
    //base:base   <-- target platform didn't satisfy constraint //base:compatible_with_all_of_linux-ubuntu_and_x86_64

The named constraint is meaningless, and just a placeholder.

Alternatively, we can rely on the select no_match_error:

Analysis of target '//base:port_test' failed; build aborted: Configurable attribute "target_compatible_with" doesn't match this configuration: Didn't match all conditions.

Here, Didn't match all conditions. is just a placeholder which can actually express all the config_setting's .

[trybka]

I hate myself for even suggesting this... but using some clever unicode...

We can yield this instead:

Dependency chain:
    //base:port_test
    //base:base   <-- target platform didn't satisfy constraint //base:compatible_with_all_of··· ∕∕tools∕cc_target_os∶linux-ubuntu and ∕∕tools∕target_cpu∶x86_64

[philsc]

Very cool! Would you happen to have an accompanying test file that you're testing these out in? Would be fun to play with this a bit. Obviously it's easy to set something up manually to play with this, but I was just curious.

[philsc]

Avoiding no_match_error would be good I think. Otherwise you get analysis errors instead of target skipping.

I.e. this should probably be "//conditions:default": [INCOMPATIBLE_TARGET], no?

[trybka]

d'oh -- good point. I was mostly down the rabbit hole testing on a single broken target.

yeah, this is a non-starter for skipping.

[philsc]

Yeah, this makes sense. I never tried to implement all_of before, but it makes sense that you can't do it with a single select() statement.

[gregestren]

It's cool to see composition of Starlark libs actually working. I always worry the "non-native" part of selects means using config_setting_group as a library call could blow up in unexpected ways. Happy to see it all remains smooth.

[trybka]

I think the only sharp/weird edge here is the fact that this has to be a named rule (which necessitated the existing_rule check). If you have alternatives for how to make unique or unnamed targets here, that would improve things, I think.

[philsc]

So... I had a thought. Would a simple implementation of all_of look like this?

def _all_of(settings):
    return settings

The target_compatible_with attribute already implements AND logic by default.

Maybe as per your comment below, maybe don't provide all_of at all? I like it there for consistency, but maybe it's superfluous?

[trybka]

That would only work if settings contained only constraint_values. In the case I want to support, raw config_settings don't work here. (Apparently anything that provides ConstraintValueInfo would work, but currently nothing else does, and that provider is behind some flag anyhow.)

[philsc]

Ah dang. Yeah, I keep forgetting about that, apologies!

[philsc]

Neat idea!

[gregestren]

What's the difference between this new value and just @platforms//:incompatible?

[trybka]

@platforms//:incompatible cannot appear twice in this attribute--so if two selects resolve to incompatible, there will be an error.

[trybka]

Very cool! Would you happen to have an accompanying test file that you're testing these out in? Would be fun to play with this a bit. Obviously it's easy to set something up manually to play with this, but I was just curious.

I'll try to add a test here.

[philsc]

Could you expand this to talk about constraint_value targets not working with all_of because of bazelbuild/bazel#13047?

As a work around, folks should use something like this if they need to mix constraint_value and config_setting targets:

target_compatible_with = [":constraint1", "constraint2"] + compatbility.all_of([":config1", ":config2"]),

[gregestren]

I commented on the bug but I'm really hoping that bug is fixable without a major effort. It's ultimately a silly circular dependency problem. Those are always awkward, but conceptually not too hard to think about ways of short circuiting.