Skip to content
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

Add --filter-platform to cargo metadata. #7376

Merged
merged 3 commits into from
Oct 28, 2019
Merged

Conversation

ehuss
Copy link
Contributor

@ehuss ehuss commented Sep 18, 2019

This adds the --filter-platform flag to cargo metadata to give users a way to filter the resolve information based on the target triple.

This is just a prototype to open for feedback. Some things that need feedback:

  • Debate the name of the flag.
  • It uses "host" as a special triple to mean the local host. Does that make sense? It seemed a little weird.
  • Should it also filter the dependencies in the "packages" array? Right now it only does resolve. I'm on the fence. It probably should, but that would be an intrusive change to rewrite the Package values.
  • Should the filtering be transitive? That is, if a package is only reachable by a specific platform, should it be removed from the resolve "nodes"? What about "packages"? Currently it is included, with the intent that you walk the resolve starting with a root (like a workspace member). But it might be surprising to see "winapi" when you filter for a unix platform.

This will need documentation before it is merged.

@rust-highfive
Copy link

r? @Eh2406

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 18, 2019
@alexcrichton
Copy link
Member

Well all the high-level comments I would have are covered by your questsions, so...

Debate the name of the flag.

In terms of bikeshedding UI, I think this has some overlap with #5133 since presumably if that went through it'd be added to cargo metadata and have roughly the same effect that this proposed flag already has.

It uses "host" as a special triple to mean the local host. Does that make sense? It seemed a little weird.

I think --filter-platform host would be the same as --filter-platform $the_actual_host, right? If so I agree it's a bit out of place for here and we probably don't want to add it just here just yet.

Should it also filter the dependencies in the "packages" array?

This is where the overlap with #5133 might be more apparent because if we were to implement that then the PackageSet and Resolve would both be pre-filtered already and would already effectively dictate this. Semantically though I feel like if you're just asking for metadata about a particular target you shouldn't get winapi anywhere (or other non-relevant dependencies for your platform)

Should the filtering be transitive?

I think this is roughly the same thing as the previous question, but I may be misunderstanding some nuance you're intending that I understand. In any case I do think that it's probably best to filter everything out as aggressively as possible in the ideal world, but having extra stuff in there in an initial implementation isn't the end of the world.

@ehuss ehuss added S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 2, 2019
@ehuss
Copy link
Contributor Author

ehuss commented Oct 8, 2019

I've update the PR with a rewrite where it filters the entire graph. I don't think avoid-dev-deps is what we really want here, since that doesn't really handle targets (in the resolver), and we do want dev-deps listed.

I considered using build_unit_dependencies directly, but since the target filtering code is so small, I figured it wasn't worth the added complexity. If things become more complicated in the future (like with feature selection), then we might consider that approach instead.

I also removed the special host target.

This still needs documentation.

Two quirks to note:

  • binary-only deps are no longer listed. I personally don't care about those (they do nothing), but I could add them back if desired, it just will be a little more awkward.
  • The "dependencies" field of the Package still lists the full set of dependencies without filtering. I could go either way on that, but it's a little harder to do. The intent in my mind is that "dependencies" is exactly what is written in Cargo.toml without modification. The resolve section is the actual resolve with whatever filtering applied.

@alexcrichton
Copy link
Member

Sorry for the delay in review, but this seems reasonable to me! r=me when you're ready to land this.

@bors
Copy link
Contributor

bors commented Oct 24, 2019

☔ The latest upstream changes (presumably #7536) made this pull request unmergeable. Please resolve the merge conflicts.

@ehuss
Copy link
Contributor Author

ehuss commented Oct 28, 2019

Added some documentation.

@bors r=alexcrichton

@bors
Copy link
Contributor

bors commented Oct 28, 2019

📌 Commit ca02e03 has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. labels Oct 28, 2019
@bors
Copy link
Contributor

bors commented Oct 28, 2019

⌛ Testing commit ca02e03 with merge 5da4b4d...

bors added a commit that referenced this pull request Oct 28, 2019
Add --filter-platform to `cargo metadata`.

This adds the `--filter-platform` flag to `cargo metadata` to give users a way to filter the resolve information based on the target triple.

This is just a prototype to open for feedback.  Some things that need feedback:

- Debate the name of the flag.
- It uses "host" as a special triple to mean the local host.  Does that make sense?  It seemed a little weird.
- Should it also filter the dependencies in the "packages" array?  Right now it only does resolve.  I'm on the fence. It probably should, but that would be an intrusive change to rewrite the Package values.
- Should the filtering be transitive?  That is, if a package is only reachable by a specific platform, should it be removed from the resolve "nodes"?  What about "packages"?  Currently it is included, with the intent that you walk the resolve starting with a root (like a workspace member).  But it might be surprising to see "winapi" when you filter for a unix platform.

This will need documentation before it is merged.
@bors
Copy link
Contributor

bors commented Oct 28, 2019

☀️ Test successful - checks-azure
Approved by: alexcrichton
Pushing 5da4b4d to master...

@bors bors merged commit ca02e03 into rust-lang:master Oct 28, 2019
bors added a commit to rust-lang/rust that referenced this pull request Oct 30, 2019
Update cargo, books.

## cargo

8 commits in 3ba5f27170db10af7a92f2b682e049397197b8fa..5da4b4d47963868d9878480197581ccbbdaece74
2019-10-22 15:05:18 +0000 to 2019-10-28 21:53:41 +0000
- Add --filter-platform to `cargo metadata`. (rust-lang/cargo#7376)
- Fix `cargo fix` not showing colors. (rust-lang/cargo#7550)
- Rephrase --manifest-path section (rust-lang/cargo#7409)
- Add a note to discourage the use of -Zminimal-versions. (rust-lang/cargo#7549)
- Fix profile override warning in a workspace. (rust-lang/cargo#7536)
- Fix some tests failing on Windows nightly. (rust-lang/cargo#7534)
- Show better error message for Windows abnormal termination. (rust-lang/cargo#7535)
- Run `apt update` before `apt install` (rust-lang/cargo#7541)

## reference

8 commits in 5b9d2fc..4b21b64
2019-10-03 22:39:10 +0200 to 2019-10-27 22:33:11 +0100
- Document `const_constructor` feature (rust-lang/reference#677)
- Add `non_exhaustive` to reference. (rust-lang/reference#609)
- Re-add rust-docs component for lintcheck (rust-lang/reference#702)
- group signed and unsigned integers in layout table (rust-lang/reference#700)
- Fix layout table rendering (rust-lang/reference#699)
- Add reference for attributes in function parameters (rust-lang/reference#657)
- Update now that proc macros can expand to macro_rules. (rust-lang/reference#694)
- Fix match in union example. (rust-lang/reference#684)

## book

8 commits in 9bb8b161963fcebc9d9ccd732ba26f42108016d5..28fa3d15b0bc67ea5e79eeff2198e4277fc61baf
2019-10-14 18:42:55 -0500 to 2019-10-29 07:16:09 -0500
- Update Ch19.1 on slice splitting (rust-lang/book#1999)
- fixed inconsistent terminology regarding enums (rust-lang/book#2022)
- Update ch15-03 code to match output. (rust-lang/book#2020)
- Fixes rust-lang/book#2039 (rust-lang/book#2040)
- Update ch15-03-drop.md (rust-lang/book#2049)
- unit type value is also a value (rust-lang/book#2061)
- Minor: remove an extraneous `.` (rust-lang/book#2059)
- Clarifications and consistent use of quotation marks (rust-lang/book#1992)

## rust-by-example

4 commits in 0b111eaae36cc4b4997684be853882a59e2c7ca7..f3197ddf2abab9abdbc029def8164f4a748b0d91
2019-10-14 18:34:25 -0300 to 2019-10-29 10:17:40 -0300
- Fix typos (rust-lang/rust-by-example#1285)
- Improve Cargo / Dependencies section (rust-lang/rust-by-example#1287)
- Improve Cargo / Build Scripts section (rust-lang/rust-by-example#1288)
- Make if_let exercise runnable (rust-lang/rust-by-example#1289)
@ehuss ehuss added this to the 1.40.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants