Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of rust-lang#124355 - workingjubilee:add-target-family-lin…
…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.
- Loading branch information