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

request: a flag to limit target list results by support tier level #3308

Open
mcandre opened this issue Apr 3, 2023 · 4 comments
Open

request: a flag to limit target list results by support tier level #3308

mcandre opened this issue Apr 3, 2023 · 4 comments

Comments

@mcandre
Copy link

mcandre commented Apr 3, 2023

Problem you are trying to solve

Hi,

I want to loop over the tier 1 and tier 2 targets and cross-compile my Rust apps for these platforms. I do this for my Rust projects in order to make it easier for non-Rust users to enjoy my command line tools!

I have a working script to do just that, called crit, based on the excellent cross tool.

https://github.com/mcandre/crit

This works (yay!) for about 80% of the available triples from rustup target list. Unfortunately, it requires hardcoding target triples to skip over, namely the tier 3 triples, for which the cross community has yet to publish stable Docker images.

Over time, this triple exclusion hardcoding represents some extra maintenance and fragility. I would prefer that rustup be able to filter by support tier as a built-in capability.

There is an HTML source of truth to get this data:

https://doc.rust-lang.org/rustc/platform-support.html

But of course HTML is not the most friendly or robust way to query the information in an automated fashion.

Solution you'd like

I would love for rustup target list to accept an optional flag, like --max-support-tier <n>.

When present, the flag elides target triples from the console output whose support tier is known to be larger than n.

Alternatively, add a new column to the target triple output lines, indicating the support tier number. Then, we still have an automated source of truth, which downstream CLI tools could reasonably handle parsing with simple regular expressions / awk / etc.

Notes

No response

@rbtcollins
Copy link
Contributor

So rustup is in the same situation your code is with respect to this: there is no intrinsic knowledge in rustup about whether a given triple is a particular tier.

Rustup consumes the channel data - https://forge.rust-lang.org/infra/channel-layout.html - to decide what is available and make downloads possible.

Secondly, rustup doesn't know what cross has image available for - there is an obvious race condition where something can move from one tier to another but not yet have a cross image.

So I don't think rustup is a good place to solve this.

Working with infra to get the metadata you want into the channel information would be the obvious way forward: once that data is present, you could then consume it as an automated source of truth (modulo the race with cross image production etc).

I'll leave this open for now, since a reasonable request would be 'show this data once its in the channel data', though I'm not entirely sure of the usefulness of that, since rustup itself doesn't have an API today, and depending on a CLI also isn't a stable interface.

@mcandre
Copy link
Author

mcandre commented Apr 22, 2023

That's fair.

Rust Forge could assist, by either:

  • Offering a URL to a TOML file providing target triple support tier information; Or
  • Peppering a stable element in the channel-layout.html DOM tree with xpath-friendly attributes.

@Rustin170506
Copy link
Member

  • Offering a URL to a TOML file providing target triple support tier information; Or
  • Peppering a stable element in the channel-layout.html DOM tree with xpath-friendly attributes.

https://github.com/rust-lang/rustup-components-history Does this website help?

@mcandre
Copy link
Author

mcandre commented Apr 27, 2023

That's similarly fragile, in terms of extracting the information by automated means.

We would need to establish a permanent DOM tree structure there. Better yet, store the data in a JSON file with a stable schema, and have the web page generate the DOM from the JSON data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants