Tracking Issue for Deprecate target_vendor #100343
Comments
pnkfelix
added
T-lang
pnkfelix
changed the title
joshtriplett
added
the
S-tracking-impl-incomplete
Being deprecated, see: * <rust-lang/lang-team#102> * <rust-lang/rust#100343>
Being deprecated, see: * <rust-lang/lang-team#102> * <rust-lang/rust#100343>
Being deprecated, see: * <rust-lang/lang-team#102> * <rust-lang/rust#100343>
|
With five "operating systems" (really, macOS, iOS, and different skins on iOS) released by Apple, we really ought to implement |
Yeah, it's tricky to do this due to how much code does It also can't be cratered, since crater tests only on Linux. Edit: I've already said this, and it's even been linked to. Lmao. |
|
Yeah. I don't think people should be expected to gouge their eyes out maintaining "every time an Apple-based OS is involved, use
It is entirely possible, at this rate, that we see another Apple OS released before the decade is out! ...But We could consider cratering a different |
…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.
…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.
|
Switching from individual |
…ngjubilee Use `target_vendor = "apple"` instead of `target_os = "..."` Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`. The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific. Note that `target_vendor` will [be deprecated in the future](rust-lang#100343), but not before an alternative (like `target_family = "apple"`) is available. While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: rust-lang#124494 Since you've talked about using `target_vendor = "apple"` in the past: r? workingjubilee CC `@simlay,` `@thomcc` `@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
…ngjubilee Use `target_vendor = "apple"` instead of `target_os = "..."` Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`. The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific. Note that `target_vendor` will [be deprecated in the future](rust-lang#100343), but not before an alternative (like `target_family = "apple"`) is available. While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: rust-lang#124494 Since you've talked about using `target_vendor = "apple"` in the past: r? workingjubilee CC `@simlay,` `@thomcc` `@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
|
In #124355 I ran the crater experiment I mentioned, and the trap did indeed get sprung! It has a number of regressions, but only 82 in total, and as usual, many of these source to a handful of crates. I believe it may be possible to best-effort lint against this behavior. The arguments already advanced justify doing so:
An alternative path forward is to persuade Cargo to change the env var they use, and to migrate everyone to the new behavior because they are relying on A final path forward, the path of least resistance, is, of course, to simply not deprecate |
Use `target_vendor = "apple"` instead of `target_os = "..."` Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`. The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific. Note that `target_vendor` will [be deprecated in the future](rust-lang/rust#100343), but not before an alternative (like `target_family = "apple"`) is available. While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: rust-lang/rust#124494 Since you've talked about using `target_vendor = "apple"` in the past: r? workingjubilee CC `@simlay,` `@thomcc` `@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
The ecosystem is already destroyed.. The amount of ninja patches to support some silly crates on visionos today is crazy... Not sure why this was not there from day 1. |
|
#123723 finished FCP, so we will have |
This is a tracking issue for the MCP "Deprecate target_vendor" (rust-lang/lang-team#102).
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Unresolved Questions
target_familymight be problematic.Implementation history
The text was updated successfully, but these errors were encountered: