-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to filter lists of targets by the platform compatibility. #12412
Comments
I see a few options here:
@konste , can you confirm that the three solutions above would address your concern? I.e. did I misunderstand what you're looking for? @gregestren , @katre, what are your thoughts on this? Do you see other/better options? |
I can confirm that we are on the same page and any of the three solutions above would solve the problem at hand. It took me some effort to figure the difference between solutions #2 and #3. From what I can see #3 is more flexible and future proof. At the same time, it seems to be less work than #2. Considering the above solution #3 seems to be the best in the longer term, although if there are any unforeseen problems with it we can fall back to #1 as a stop-gap. Thank you for looking into it! |
I like the idea of 3. We already have an Aside from the incompatibility issue, do you you have any attachment to |
With 3, would it be possible for a rule to return |
@gregestren in this particular case we use filegroup as a "funnel" to gather the targets we want for the given configuration and don't use any filegroup specific features, so it would not be a problem to replace it with the custom rule which does the filtering based on the srcs providers. @moroten in our case "funnel" rules themselves are always compatible, so we would not need the ability to return IncompatiblePlatformProvider, but when you mentioned it - it looks like natural thing to do. |
I have a proof-of-concept up here: That patch lets you filter targets with |
Another API variation could be to omit the So any target with That would give Starlark rules 100% flexibility in determining what makes then incompatible or not (similar to what I think @moroten is suggesting?) and not require more API surface area on |
@gregestren , could you elaborate a little bit on how a Starlark rule would access incompatible dependencies with your proposed change? |
@philwo beat me to the punch. I have the same question. I also noticed that you use this construct: |
@philsc you're right! I didn't think of that. |
@gregestren , would the next step here be to create a proposal? |
Start up a doc at https://www.bazel.build/designs/index.html (maybe with @konste as co-author if interested?) Try to summarize the concerns expressed here and suggest what inspires you! If this involves a change to the Starlark API, which it sounds like it will whatever the exact proposal, just note that's going to require its own review consideration. i.e. we need to clearly argue how this would grow the API in a coherent, non-cluttered, maintainable way. |
Setting as P1 since @philsc is actively paying attention to this now. Please feel free to adjust priority any time if this is inaccurate. |
Sounds good, thanks @gregestren! |
I will gladly help with reviewing the document, testing the prototypes and anything I can technically handle. |
Cool, thanks! I started a doc here: https://docs.google.com/document/d/1c1wnev-8mBHdOGQuom9hdXhfuBPlT9O8wplY-HuvXZc/edit?usp=sharing I haven't actually put in any useful information yet. |
@konste , could you please take a look at the doc when you get a chance? You should have full edit access. |
Thanks @philsc ! I will try to get to it soon. |
That patch is unrelated to this issue. That patch is to fix an issue where creating a filegroup with incompatible dependencies would cause |
@philsc @gregestren I just published my attempt at the alternative design here. Hoping to make it simpler, less invasive and with that hopefully implemented sooner. |
@konste , mind making the doc viewable publicly? |
@AustinSchuh, of course! Please try now. I am new to Google Docs and did not know how to do it initially. |
Apologies @konste . I've been in full vacation mode for the past few weeks. I'll take a look soon. |
I'm not working on any filtering features. I'm not seeing how filtering would help with the linked issue. It sounds to me like that linked issue wants bazel to skip an explicitly requested target. That seems very different from automatically filtering dependencies. |
Description of the problem / feature request:
Newly introduced feature allows filtering the requested targets and gracefully removes those incompatible with the requested platform. All targets which depend on incompatible targets also considered incompatible and excluded from the build.
In case we have
filegroup
or another rule which accepts the list of targets we don't want to invalidate it only because one of the targets in the list appeared to be incompatible. We want to skip incompatible targets, but let the rest of the list proceed with the build.Feature requests: what underlying problem are you trying to solve with this feature?
To build specific category of artifacts (like "binaries") we have something like the following in our root BUILD file:
Each item in the list is defined in a corresponding external workspace as a filegroup which may pull in direct targets and more transitive filegroups. The problem is that not all targets are suitable for all possible target platforms although each target knows what platforms it is compatible with.
target_compatible_with
attribute does not solve this problem completely as any incompatible target would invalidate the whole filegroup, so we need some mechanism to allow for the filtering based on that attribute.What operating system are you running Bazel on?
Windows, Mac, Linux
3.7.0
The text was updated successfully, but these errors were encountered: