Repository navigation
Tracking Issue for deprecating target_vendor #100343
Description
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
- Implement the MCP (cc @rust-lang/lang -- there are solution sketches written out on Deprecate target_vendor lang-team#102 (comment))
- Adjust documentation (see instructions on rustc-dev-guide)
- Stabilization PR (see instructions on rustc-dev-guide)
Unresolved Questions
- @scottmcm asked "What, technically, do you expect "deprecated" to mean here?"
- @thomcc wondered if adding more values to
target_familymight be problematic.
Activity
[-]Tracking Issue for XXX[/-][+]Tracking Issue for Deprecate target_vendor[/+]Remove usage of target_vendor = "apple"
Remove usage of target_vendor = "apple"
Remove usage of target_vendor = "apple"
workingjubilee commentedon Apr 18, 2024
With five "operating systems" (really, macOS, iOS, and different skins on iOS) released by Apple, we really ought to implement
target_family = "apple"first. Either we can land that without destroying the ecosystem, or we need to reconsider this entire idea.thomcc commentedon Apr 18, 2024
Yeah, it's tricky to do this due to how much code does
env::var("CARGO_CFG_TARGET_FAMILY").unwrap_or_default() == "unix"in build scripts as a way to detect unix (usually not verbatim, it's more common to see target family extracted, and then later matched on with arms for"unix"and"windows"). Technically this is already wrong, but only on a few fairly obscure targets (it also may not have been wrong when they wrote it, as target_family was initially single-valued).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.
workingjubilee commentedon Apr 18, 2024
Yeah. I don't think people should be expected to gouge their eyes out maintaining "every time an Apple-based OS is involved, use
target_osfor each one instead oftarget_vendorfor all of them, despite the fact that they use basically the same tech". Consider the publishing dates for the current set of Apple OS:It is entirely possible, at this rate, that we see another Apple OS released before the decade is out! ...But
target_family = "apple"is equally fine.We could consider cratering a different
target_familythat would affect Linux.Auto merge of rust-lang#124355 - workingjubilee:add-target-family-lin…
Auto merge of rust-lang#124355 - workingjubilee:add-target-family-lin…
workingjubilee commentedon Apr 30, 2024
Switching from individual
target_osto a singletarget_vendorappears to have revealed several bugs or OS-based variations without clear reasoning in the implementations of several Apple OS for libstd. I no longer believe this is a mere aesthetics or conciseness issue, it is about correctness.Auto merge of rust-lang#124491 - madsmtm:target_vendor-apple, r=worki…
Auto merge of rust-lang#124491 - madsmtm:target_vendor-apple, r=worki…
workingjubilee commentedon May 2, 2024
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:
target_familyan arraytarget_familyvalues going forwardAn 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
CARGO_CFG_TARGET_FAMILYworking the way they currently expect. This seems strictly worse, as people will likely develop the habit of doing exact comparisons anyways inside their build scripts with the new env var, and we will be churning the entire damn ecosystem for no reason.A final path forward, the path of least resistance, is, of course, to simply not deprecate
target_vendorafter all. However, I believe fixing these obstacles has other merits, so I don't really buy it.Auto merge of #124491 - madsmtm:target_vendor-apple, r=workingjubilee
sinkingsugar commentedon Jul 2, 2024
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.
madsmtm commentedon Nov 3, 2024
#123723 finished FCP, so we will have
std::os::darwin. In light of that, I think we should prefertarget_family = "darwin"overtarget_family = "apple"(once we get to actually making that change).Fix test that assumes `CARGO_CFG_TARGET_FAMILY` is a single value (#1…
madsmtm commentedon Oct 10, 2025
I've opened #147545 for adding a FCW that would warn against the problem with
CARGO_CFG_TARGET_FAMILYthat @thomcc noted.Compare against `CARGO_CFG_TARGET_FAMILY` in a multi-valued fashion
Compare against `CARGO_CFG_TARGET_FAMILY` in a multi-valued fashion
Compare against `CARGO_CFG_TARGET_FAMILY` in a multi-valued fashion
Berrysoft commentedon Apr 17, 2026
How should we distinguish "pc", "uwp", and "win7" for windows targets after
target_vendorbeing deprecated?madsmtm commentedon Apr 17, 2026
For
uwp, usetarget_abi = "uwp"(should probably be added to the target docs).For
win7, rust-lang/rfcs#3750 would be the proper way.Berrysoft commentedon Apr 17, 2026
How to distinguish
uwp-msvcanduwp-gnuthen?[-]Tracking Issue for Deprecate target_vendor[/-][+]Tracking Issue for deprecating `target_vendor`[/+]madsmtm commentedon Apr 17, 2026
target_env = "msvc"vs.target_env = "gnu"?