Print name of env var in `--print=deployment-target` by madsmtm · Pull Request #133041 · rust-lang/rust

madsmtm · 2024-11-14T16:55:49Z

The deployment target environment variable is OS-specific, and if you're in a place where you're asking rustc for the deployment target, you're likely to also wanna know the name of the environment variable. I myself wanted this for some code I'm working on in bootstrap, for example.

Behaviour before this PR:

$ rustc --print=deployment-target --target=aarch64-apple-darwin
deployment_target=11.0
$ rustc --print=deployment-target --target=aarch64-apple-visionos
deployment_target=1.0

Behaviour after this PR:

$ rustc --print=deployment-target --target=aarch64-apple-darwin
MACOSX_DEPLOYMENT_TARGET=11.0
$ rustc --print=deployment-target --target=aarch64-apple-visionos
XROS_DEPLOYMENT_TARGET=1.0

My belief is that this option is extremely rarely used in general, and a GitHub search for "rustc print deployment-target" seems to confirm this, it revealed only the following actual pieces of code using this:

maturin does .split('=').last(), so it will continue to work after this change, but cc v1.0.84 did .strip_prefix("deployment_target=") since this PR, so it would break. That's probably fine though, it was broken in a lot of scenarios anyway, and got reverted in v1.0.85.

So while this is technically a breaking change, I really doubt that anyone is going to observe it, so it's probably fine.

@BlackHoleFox wdyt?

@rustbot label O-apple
r? compiler

madsmtm · 2024-11-14T17:02:21Z

This also makes it easier to use in shell scripts, you can now do for example:

export $(rustc --print=deployment-target --target=$MY_APPLE_TARGET)
# Or
env $(rustc --print=deployment-target --target=$MY_APPLE_TARGET) clang --target $MY_APPLE_TARGET foo.c

madsmtm · 2024-11-15T08:55:34Z

Rustbot didn't seem to pick it up the first time, so:

@rustbot label O-apple

fee1-dead · 2024-11-15T09:53:21Z

r? compiler

BlackHoleFox · 2024-11-15T17:36:14Z

iirc one of the reasons I made it print without the variable name is so it has a higher chance of working with non-Apple OSes whenever RFCs/interested parties get along to making cfg()s for configuring what version of Windows, Android, etc a Rust build should target. I don't think its set in stone those would have env variables to go along with?

madsmtm · 2024-11-16T01:37:02Z

iirc one of the reasons I made it print without the variable name is so it has a higher chance of working with non-Apple OSes whenever RFCs/interested parties get along to making cfg()s for configuring what version of Windows, Android, etc a Rust build should target. I don't think its set in stone those would have env variables to go along with?

That's fair reasoning, although then IMO it should've been called rustc --print=target-os-version, and honestly just returned it directly without the deployment_target= in front.

Given that we now have some cruft in the front anyhow, I think we might as well use it for something useful. Besides, if this is expanded to other targets, they can just use deployment_target= like done today.

madsmtm · 2024-11-16T04:30:54Z

#133092 is what I wanted it for, btw

davidtwco

I think this makes sense, "deployment target" seems to be very Apple-specific terminology, so I think if we wanted to introduce a "target OS version" alternative that supported more platforms (and just returned the deployment target for Apple platforms) then we could still do that and keep this as Apple-specific.

davidtwco · 2024-11-21T11:58:44Z

Based on your description, it doesn't seem like this is likely to break anything, but we can always revert it if we get reports of issues.

@bors r+

bors · 2024-11-21T11:58:47Z

📌 Commit 44933b5 has been approved by davidtwco

It is now in the queue for this repository.

…v-var, r=davidtwco Print name of env var in `--print=deployment-target` The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the name of the environment variable. I myself wanted this for some code I'm working on in bootstrap, for example. Behaviour before this PR: ```console $ rustc --print=deployment-target --target=aarch64-apple-darwin deployment_target=11.0 $ rustc --print=deployment-target --target=aarch64-apple-visionos deployment_target=1.0 ``` Behaviour after this PR: ```console $ rustc --print=deployment-target --target=aarch64-apple-darwin MACOSX_DEPLOYMENT_TARGET=11.0 $ rustc --print=deployment-target --target=aarch64-apple-visionos XROS_DEPLOYMENT_TARGET=1.0 ``` My _belief_ is that this option is extremely rarely used in general, and a GitHub search for "rustc print deployment-target" seems to confirm this, it revealed only the following actual pieces of code using this: - https://github.com/PyO3/maturin/blob/b292ef69349f2a56cb8ab1b59fda0be3d3b9f138/src/build_context.rs#L1199-L1220 - https://github.com/rust-lang/cc-rs/blob/daab9244b03e244c4f2511944870d719c443f61f/src/lib.rs#L3422-L3426 `maturin` does `.split('=').last()`, so it will continue to work after this change, but `cc v1.0.84` did `.strip_prefix("deployment_target=")` since [this PR](rust-lang/cc-rs#848), so it would break. That's _probably_ fine though, it was broken in a lot of scenarios anyway, and [got](rust-lang/cc-rs#901) [reverted](rust-lang/cc-rs#943) in `v1.0.85`. So while this is _technically_ a breaking change, I really doubt that anyone is going to observe it, so it's probably fine. `@BlackHoleFox` wdyt? `@rustbot` label O-apple r? compiler

…v-var, r=davidtwco Print name of env var in `--print=deployment-target` The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the name of the environment variable. I myself wanted this for some code I'm working on in bootstrap, for example. Behaviour before this PR: ```console $ rustc --print=deployment-target --target=aarch64-apple-darwin deployment_target=11.0 $ rustc --print=deployment-target --target=aarch64-apple-visionos deployment_target=1.0 ``` Behaviour after this PR: ```console $ rustc --print=deployment-target --target=aarch64-apple-darwin MACOSX_DEPLOYMENT_TARGET=11.0 $ rustc --print=deployment-target --target=aarch64-apple-visionos XROS_DEPLOYMENT_TARGET=1.0 ``` My _belief_ is that this option is extremely rarely used in general, and a GitHub search for "rustc print deployment-target" seems to confirm this, it revealed only the following actual pieces of code using this: - https://github.com/PyO3/maturin/blob/b292ef69349f2a56cb8ab1b59fda0be3d3b9f138/src/build_context.rs#L1199-L1220 - https://github.com/rust-lang/cc-rs/blob/daab9244b03e244c4f2511944870d719c443f61f/src/lib.rs#L3422-L3426 `maturin` does `.split('=').last()`, so it will continue to work after this change, but `cc v1.0.84` did `.strip_prefix("deployment_target=")` since [this PR](rust-lang/cc-rs#848), so it would break. That's _probably_ fine though, it was broken in a lot of scenarios anyway, and [got](rust-lang/cc-rs#901) [reverted](rust-lang/cc-rs#943) in `v1.0.85`. So while this is _technically_ a breaking change, I really doubt that anyone is going to observe it, so it's probably fine. ``@BlackHoleFox`` wdyt? ``@rustbot`` label O-apple r? compiler

Rollup of 13 pull requests Successful merges: - rust-lang#130867 (distinguish overflow and unimplemented in Step::steps_between) - rust-lang#131859 (Update TRPL to add new Chapter 17: Async and Await) - rust-lang#132090 (Stop being so bail-y in candidate assembly) - rust-lang#132658 (Detect const in pattern with typo) - rust-lang#133041 (Print name of env var in `--print=deployment-target`) - rust-lang#133102 (aarch64 softfloat target: always pass floats in int registers) - rust-lang#133159 (Don't allow `-Zunstable-options` to take a value ) - rust-lang#133217 ([AIX] Add option -X32_64 to the "strip" command) - rust-lang#133237 (Minimally constify `Add`) - rust-lang#133238 (re-export `is_loongarch_feature_detected`) - rust-lang#133286 (Re-delay a resolve `bug` related to `Self`-ctor in patterns) - rust-lang#133301 (Add code example for `wrapping_neg` method for signed integers) - rust-lang#133313 (Use arc4random of libc for RTEMS target) Failed merges: - rust-lang#133215 (Fix missing submodule in `./x vendor`) r? `@ghost` `@rustbot` modify labels: rollup

jieyouxu · 2024-11-22T11:09:30Z

Failed in rollup:

---- [run-make] tests/run-make/apple-sdk-version stdout ----
[trimmed]
--- stderr -------------------------------
thread 'main' panicked at /Users/runner/work/rust/rust/tests/run-make/apple-sdk-version/rmake.rs:30:70:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

@bors r-

The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the environment variable.

madsmtm · 2024-11-22T19:57:49Z

Oops, fixed now.

@rustbot ready

davidtwco · 2024-12-02T15:14:39Z

@bors r+

bors · 2024-12-02T15:14:42Z

📌 Commit 431c500 has been approved by davidtwco

It is now in the queue for this repository.

…v-var, r=davidtwco Print name of env var in `--print=deployment-target` The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the name of the environment variable. I myself wanted this for some code I'm working on in bootstrap, for example. Behaviour before this PR: ```console $ rustc --print=deployment-target --target=aarch64-apple-darwin deployment_target=11.0 $ rustc --print=deployment-target --target=aarch64-apple-visionos deployment_target=1.0 ``` Behaviour after this PR: ```console $ rustc --print=deployment-target --target=aarch64-apple-darwin MACOSX_DEPLOYMENT_TARGET=11.0 $ rustc --print=deployment-target --target=aarch64-apple-visionos XROS_DEPLOYMENT_TARGET=1.0 ``` My _belief_ is that this option is extremely rarely used in general, and a GitHub search for "rustc print deployment-target" seems to confirm this, it revealed only the following actual pieces of code using this: - https://github.com/PyO3/maturin/blob/b292ef69349f2a56cb8ab1b59fda0be3d3b9f138/src/build_context.rs#L1199-L1220 - https://github.com/rust-lang/cc-rs/blob/daab9244b03e244c4f2511944870d719c443f61f/src/lib.rs#L3422-L3426 `maturin` does `.split('=').last()`, so it will continue to work after this change, but `cc v1.0.84` did `.strip_prefix("deployment_target=")` since [this PR](rust-lang/cc-rs#848), so it would break. That's _probably_ fine though, it was broken in a lot of scenarios anyway, and [got](rust-lang/cc-rs#901) [reverted](rust-lang/cc-rs#943) in `v1.0.85`. So while this is _technically_ a breaking change, I really doubt that anyone is going to observe it, so it's probably fine. `@BlackHoleFox` wdyt? `@rustbot` label O-apple r? compiler

…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#132723 (Unify `sysroot_target_{bin,lib}dir` handling) - rust-lang#133041 (Print name of env var in `--print=deployment-target`) - rust-lang#133325 (Reimplement `~const` trait specialization) - rust-lang#133395 (Add simd_relaxed_fma intrinsic) - rust-lang#133517 (Deeply normalize when computing implied outlives bounds) - rust-lang#133785 (Add const evaluation error UI test.) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of rust-lang#133041 - madsmtm:print-deployment-target-env-var, r=davidtwco Print name of env var in `--print=deployment-target` The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the name of the environment variable. I myself wanted this for some code I'm working on in bootstrap, for example. Behaviour before this PR: ```console $ rustc --print=deployment-target --target=aarch64-apple-darwin deployment_target=11.0 $ rustc --print=deployment-target --target=aarch64-apple-visionos deployment_target=1.0 ``` Behaviour after this PR: ```console $ rustc --print=deployment-target --target=aarch64-apple-darwin MACOSX_DEPLOYMENT_TARGET=11.0 $ rustc --print=deployment-target --target=aarch64-apple-visionos XROS_DEPLOYMENT_TARGET=1.0 ``` My _belief_ is that this option is extremely rarely used in general, and a GitHub search for "rustc print deployment-target" seems to confirm this, it revealed only the following actual pieces of code using this: - https://github.com/PyO3/maturin/blob/b292ef69349f2a56cb8ab1b59fda0be3d3b9f138/src/build_context.rs#L1199-L1220 - https://github.com/rust-lang/cc-rs/blob/daab9244b03e244c4f2511944870d719c443f61f/src/lib.rs#L3422-L3426 `maturin` does `.split('=').last()`, so it will continue to work after this change, but `cc v1.0.84` did `.strip_prefix("deployment_target=")` since [this PR](rust-lang/cc-rs#848), so it would break. That's _probably_ fine though, it was broken in a lot of scenarios anyway, and [got](rust-lang/cc-rs#901) [reverted](rust-lang/cc-rs#943) in `v1.0.85`. So while this is _technically_ a breaking change, I really doubt that anyone is going to observe it, so it's probably fine. ``@BlackHoleFox`` wdyt? ``@rustbot`` label O-apple r? compiler

fmease · 2024-12-04T23:21:16Z

sync @bors r-

madsmtm changed the title ~~Print env var in --print=deployment-target~~ Print name of env var in --print=deployment-target Nov 14, 2024

rustbot assigned fee1-dead Nov 14, 2024

rustbot added A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 14, 2024

This comment was marked as off-topic.

Sign in to view

rustbot added the O-apple Operating system: Apple / Darwin (macOS, iOS, tvOS, visionOS, watchOS) label Nov 15, 2024

rustbot assigned davidtwco and unassigned fee1-dead Nov 15, 2024

davidtwco approved these changes Nov 21, 2024

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 21, 2024

GuillaumeGomez mentioned this pull request Nov 21, 2024

Rollup of 8 pull requests #133296

Closed

jhpratt mentioned this pull request Nov 22, 2024

Rollup of 13 pull requests #133329

Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 22, 2024

Print env var in --print=deployment-target

431c500

The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the environment variable.

madsmtm force-pushed the print-deployment-target-env-var branch from 44933b5 to 431c500 Compare November 22, 2024 19:50

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 22, 2024

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 2, 2024

jhpratt mentioned this pull request Dec 3, 2024

Rollup of 10 pull requests #133786

Closed

matthiaskrgr mentioned this pull request Dec 3, 2024

Rollup of 6 pull requests #133788

Merged

bors merged commit 3ec2107 into rust-lang:master Dec 3, 2024

rustbot added this to the 1.85.0 milestone Dec 3, 2024

madsmtm deleted the print-deployment-target-env-var branch December 3, 2024 12:56

matthiaskrgr mentioned this pull request Dec 3, 2024

Rollup of 8 pull requests #133814

Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 4, 2024

Uh oh!

Conversation

madsmtm commented Nov 14, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as off-topic.

madsmtm commented Nov 14, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

madsmtm commented Nov 15, 2024

Uh oh!

fee1-dead commented Nov 15, 2024

Uh oh!

BlackHoleFox commented Nov 15, 2024

Uh oh!

madsmtm commented Nov 16, 2024

Uh oh!

madsmtm commented Nov 16, 2024

Uh oh!

davidtwco left a comment

Choose a reason for hiding this comment

Uh oh!

davidtwco commented Nov 21, 2024

Uh oh!

bors commented Nov 21, 2024

Uh oh!

jieyouxu commented Nov 22, 2024

Uh oh!

madsmtm commented Nov 22, 2024

Uh oh!

davidtwco commented Dec 2, 2024

Uh oh!

bors commented Dec 2, 2024

Uh oh!

fmease commented Dec 4, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

madsmtm commented Nov 14, 2024 •

edited

Loading

madsmtm commented Nov 14, 2024 •

edited

Loading