print option to dump target spec as JSON #38061
Conversation
|
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
|
/cc @alexcrichton Based on our chat on IRC today. For some background this is a rebased version of #32847. For some background please see discussions at rust-lang/cargo#2616 and #34980. |
|
Thanks for the PR @cardoe! @rust-lang/tools, thoughts about exposing this? I continue to be perpetually uneasy about the stability and such of target specs, and placing them so front-and-center may make it harder to make tweaks to them in the future. Despite that, however, it's a reality that they exist and they're expected to work, so there may not be much debate about that. |
|
I feel like its necessary to use target specs, so unless we have a plan for an alternative we need to expose this sort of thing. I don't have an opinion on whether target specs are actually a good scheme or not, so I can't say whether we should think of an alternative |
|
So I don't want this PR to become whether target specs are a good idea or not and whether they are implemented in the best way or not. I just want to make that clear because I feel like the discussion on my PRs in this area devolve into that. The best documentation for the target specs is really the code. There's RFC 131 but that doesn't enumerate all the options. Each version of Rust has iteratively changed the target specs and tracking those changes is made harder due to having to read the code to know what has changed. This would allow people to dump a built-in spec as JSON and see the differences. |
|
Please feature gate this. |
|
Discussed at tools triage today and yeah the conclusion is that with a feature gate this should be good to go. Could you also perhaps rename this to "target-spec-json" or "json-target-spec" to emphasize the json aspect as well? |
|
Will do to both requests. Not quite sure how to feature gate something but I'm sure I can find an example in the code base. Looking at the existing options most of them start with "target-" so maybe "target-spec-json" is the best? |
|
Sure yeah "target-spec-json" sounds good. You can check for unstable features by checking for |
|
I'm not sure how I'd leave the flag out of the getopt parser since that string of the valid values to |
To allow manipulation of the options that appear in --print, convert it to a vector. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
|
Oh we'd always have it defined as an option, and then right before we actually take this action we'd assert that we're on the nightly channel. |
|
Oh, well I made it not visible on non-nightly versions. I can drop that first patch if you'd prefer. |
This option provides the user the ability to dump the configuration that is in use by rustc for the target they are building for. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
This is a very basic test of the --print target-spec feature. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
|
@bors: r+ Looks good to me, thanks! |
|
📌 Commit 7151b5a has been approved by |
print option to dump target spec as JSON This lets the user dump out the target spec that the compiler is using. This is useful to people defining their own target.json to compare it against existing targets or understand how different targets change internal settings. It is also potentially useful for Cargo to determine if something has changed with a target and it needs to rebuild things.
|
So what do I need to do to propose this flag as a stable flag in the future? Wait a certain number of releases? |
|
@cardoe oh oops we try to have a tracking issue for all unstable features (I forgot to request on here) which tracks stabilization. We move that to "fcp for merge" when we feel it's ready and then once the tools team signs off it'll go into stable. Do you want to open an issue to track this? I'll tag it appropriately. |
Since 8285ab5, which was merged in with rust-lang#38061, the help for the --print option is missing the surrounding [ ] around the possible options. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
fix help for the --print option Since 8285ab5, which was merged in with rust-lang#38061, the help for the --print option is missing the surrounding [ ] around the possible options. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Since 8285ab5, which was merged in with rust-lang#38061, the help for the --print option is missing the surrounding [ ] around the possible options. Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
This lets the user dump out the target spec that the compiler is using. This is useful to people defining their own target.json to compare it against existing targets or understand how different targets change internal settings. It is also potentially useful for Cargo to determine if something has changed with a target and it needs to rebuild things.