support resolver = "2" target-specific features#1710
support resolver = "2" target-specific features#1710UebelAndre merged 1 commit intobazelbuild:mainfrom
resolver = "2" target-specific features#1710Conversation
|
I wanted to give this a spin (as it's a feature that I've been hoping for for a long time), but sadly I didn't get too far. When trying to re-pin ( My project consists of one workspace Not sure if that is useful feedback, or if that's a known limitation of the current in-development state (feel free to ignore it if that's the case). If you need any more information, I'd be happy to help. |
|
@hobofan -- Thanks, that'd definitely useful feedback. I'll dig into this... |
5325e30 to
71a67f1
Compare
00ef26e to
88e8e5a
Compare
|
@hobofan -- Would you mind trying this latest snapshot and see if it works for you? |
|
👍 Doing the same thing as earlier now worked like a charm! I can't say anything about the correctness of the splicing yet, as I have to convert a few more parts of the project to see if that worked as expected, but it's looking good so far. |
08ff7d7 to
cf1b233
Compare
9a3db95 to
6399d38
Compare
|
@UebelAndre please take a look at your convenience. The CI failures are unrelated (due to errors when attempting to install |
6399d38 to
194f759
Compare
28b94a5 to
e37fe95
Compare
UebelAndre
left a comment
There was a problem hiding this comment.
Looking really good, thank you for working on this!
8cf3f37 to
b002869
Compare
e3d2e8a to
d8153a4
Compare
|
Note that the current CI failure is likely due to bazelbuild/continuous-integration#1540 |
UebelAndre
left a comment
There was a problem hiding this comment.
Amazing effort and amazing work! Thank you so much for working on this! I left a few nits if you don't mind and can merge after a rebase 😄
fc55efe to
42debde
Compare
|
Thanks for the review!! |
|
Thanks again! But for future reference, GitHub does not do a good job at reporting diffs after a rebase. Pull-requests are much easier to review if squashing or rebasing waits until just before it's merged. That said, I was happy to deal with the Github user experience for this change. Amazing work! |
|
I'm sorry for the reviewing trouble from rebasing. I don't use Github all that much.... but I'm happy to learn to do better... Is the preferred approach to create a chain of merge commits with both PR updates and integrating changes from head, and then squash everything once at the end? Or what's the best practice? (Or is there a good "how to Github less badly" document somewhere?) |
No worries! I don't know if there's a guide, this is something I've come to experience in working on this project. I think in general, if you can avoid rewriting history until the review is complete it'll be smoother for the reviewer. This incremental changes are highlighted and easier to see. |
The Cargo [Feature Resolver version 2](https://doc.rust-lang.org/cargo/reference/resolver.html#feature-resolver-version-2) behavior is currently not supported by the `cargo metadata` sub command (rust-lang/cargo#9863) which `crate_universe` uses to determine the dependencies of a target, leading to inaccuracies when dependencies are introduced via feature resolution for a particular configuration. In #1710 functionality was added to use `cargo tree` to perform feature resolution for each supported platform. This change expands on this trick to collect dependency information at the same time and use that to determine whether or not to include optional dependencies located in standard `cargo metadata` output in the rendered Bazel targets. Non optional or `target.cfg` (conditional) dependencies behave as they did before this change. Implementation details: - `FeatureGenerator` was replaced by `TreeResolver` - Optional dependencies are now rendered as selects on explicit platforms. This will expand the size of `cargo-bazel-lock.json` files but is expected to be more correct.
I haven't had much time to work on this the last week or so. It's still pretty thin on tests.
However, I figured I'd get this out here for some initial feedback.
This should more or less fix (I think) #1662