-
Notifications
You must be signed in to change notification settings - Fork 13.3k
[EXPERIMENT] Crater adding target_family = "linux"
#124355
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
base: master
Are you sure you want to change the base?
[EXPERIMENT] Crater adding target_family = "linux"
#124355
Conversation
r? @wesleywiser rustbot has assigned @wesleywiser. Use |
These commits modify compiler targets. |
Someday I will remember to r? @ghost preemptively. |
This comment has been minimized.
This comment has been minimized.
Failed to set assignee to
|
@bors try |
…ux, r=<try> [EXPERIMENT] Crater adding `target_family = "linux"` The lang team proposed, a while back, [deprecating `target_vendor`](rust-lang#100343). With five operating systems all from Apple, using very similar, unifying characteristics for each, it is untenable to ask people to `cfg(any(target_os = "macos", target_os = "ios", target_os = "watchos", target_os = "tvos", target_os = "visionos"))`. It is commonly preferred to use `target_vendor = "apple"` for things that are true for all of these OS variants, and we have to offer a replacement that is equally parsimonious. [The "obvious" choice is to add a `target_family = "apple"`](rust-lang/lang-team#102 (comment)). However, [there is a concern that adding a `target_family = "apple"` won't work without massive ecosystem breakage, because of poorly-designed build scripts](rust-lang/lang-team#102 (comment)). But we currently can't crater a test of that effectively, because most tests only test host compilation, and crater only runs on Linux. We could, however, test adding a hypothetical `target_family = "linux"`! This would be a hypothetical `target_family` that unites both `target_os = "linux"` and `target_os = "android"` targets. This isn't necessarily an "apples to apples" comparison (more like "penguins to robots"?) but it seems worth trying. Note that this is **not** a proposal to actually add such a `target_family`. I don't have any arguments about the merits beyond "it seems like a plausible target family we may one day add, it can be added in a way that disrupts relevant build scripts, and it impacts a 'high-value' target". For maximum coverage I have in fact added the relevant `target_family = "apple"` and `target_family = "linux"` also just in case any test suites somehow run cross-compilation tests.
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
cc @Urgau I'm not quite sure how far the check-cfg work has come along. Should I be concerned about these test failures as an omen for this crater run? |
The rustc
No, no need to be concerned; most of the check-cfg tests are regression tests, they are mostly here to make sure that if something changes, it is intentional. you can bless them when you're ready |
Co-authored-by: Urgau <3616612+Urgau@users.noreply.github.com>
Okay! Thanks for that info! I thought about it and I think this is the only thing that can possibly bring us closer to an answer, atm, of "will this work", without doing a bunch of work no one wants to do anyways. |
@bors try |
…ux, r=<try> [EXPERIMENT] Crater adding `target_family = "linux"` The lang team proposed, a while back, [deprecating `target_vendor`](rust-lang#100343). With five operating systems all from Apple, using very similar, unifying characteristics for each, it is untenable to ask people to `cfg(any(target_os = "macos", target_os = "ios", target_os = "watchos", target_os = "tvos", target_os = "visionos"))`. It is commonly preferred to use `target_vendor = "apple"` for things that are true for all of these OS variants, and we have to offer a replacement that is equally parsimonious. [The "obvious" choice is to add a `target_family = "apple"`](rust-lang/lang-team#102 (comment)). However, [there is a concern that adding a `target_family = "apple"` won't work without massive ecosystem breakage, because of poorly-designed build scripts](rust-lang/lang-team#102 (comment)). But we currently can't crater a test of that effectively, because most tests only test host compilation, and crater only runs on Linux. We could, however, test adding a hypothetical `target_family = "linux"`! This would be a hypothetical `target_family` that unites both `target_os = "linux"` and `target_os = "android"` targets. This isn't necessarily an "apples to apples" comparison (more like "penguins to robots"?) but it seems worth trying. Note that this is **not** a proposal to actually add such a `target_family`. I don't have any arguments about the merits beyond "it seems like a plausible target family we may one day add, it can be added in a way that disrupts relevant build scripts, and it impacts a 'high-value' target". For maximum coverage I have in fact added the relevant `target_family = "apple"` and `target_family = "linux"` also just in case any test suites somehow run cross-compilation tests.
The job Click to see the possible cause of the failure (guessed by this bot)
|
☀️ Try build successful - checks-actions |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
Cursory impressions:
|
I've filed PRs to fix the specific affected crates you identified: |
Make it clear that `CARGO_CFG_TARGET_FAMILY` is multi-valued `target_family` / `CARGO_CFG_TARGET_FAMILY` can take multiple values, but this is not particularly clear in the documentation. To resolve this, I've changed the example to document this. [A crater run](rust-lang/rust#124355 (comment)) found a few instances where this value was incorrectly assumed to be a single value.
All the affected crates have been fixed, and new versions have been released for the crates that broke the most, I don't know how these things go, but would it make sense to do another crater run? And would the way forwards be to try to lint, do you think? |
Oh nice! |
yeah if you could draft a lint that triggers only inside a build script (I believe |
Sorry to disappoint, I probably cannot at all (yet) |
I don't think it should be considered absolutely blocking, fwiw, @madsmtm, it's just hard to figure out how to migrate people without a something. |
The lang team proposed, a while back, deprecating
target_vendor
.With five operating systems all from Apple, using very similar, unifying characteristics for each, it is untenable to ask people to
cfg(any(target_os = "macos", target_os = "ios", target_os = "watchos", target_os = "tvos", target_os = "visionos"))
. It is commonly preferred to usetarget_vendor = "apple"
for things that are true for all of these OS variants, and we have to offer a replacement that is equally parsimonious.The "obvious" choice is to add a
target_family = "apple"
. However, there is a concern that adding atarget_family = "apple"
won't work without massive ecosystem breakage, because of poorly-designed build scripts. But we currently can't crater a test of that effectively, because most tests only test host compilation, and crater only runs on Linux.We could, however, test adding a hypothetical
target_family = "linux"
! This would be a hypotheticaltarget_family
that unites bothtarget_os = "linux"
andtarget_os = "android"
targets. This isn't necessarily an "apples to apples" comparison (more like "penguins to robots"?) but it seems worth trying.Note that this is not a proposal to actually add such a
target_family
. I don't have any arguments about the merits beyond "it seems like a plausible target family we may one day add, it can be added in a way that disrupts relevant build scripts, and it impacts a 'high-value' target".For maximum coverage I have in fact added the relevant
target_family = "apple"
andtarget_family = "linux"
also just in case any test suites somehow run cross-compilation tests.