Expose cargo output format verison to build scripts

[CamJN]

Problem

Now that cargo is getting a new cargo:: build script output format in 1.77, it would be really nice to be able to tell which version of cargo is running the build script, so that I can output the correct syntax and not bump my required rust version to 1.77.

Proposed Solution

Either an env var with the cargo output format version number something like CARGO_OUTPUT_FORMAT=v2 or a config like #[cfg(not(cargo_output_format = "v1"))] or cfg!(cargo_output_format = "v2").

Notes

I realize the old syntax isn't planned to be removed, so this is just a nice-to-have not a requirement. If the old syntax does get deprecated or removed this moves more into a required-feature type role.

[weihanglo]

so that I can output the correct syntax and not bump my required rust version to 1.77.

Could you elaborate what do "I" refer to here, and who is going to consume the proposed environment? A more detailed use case would help.

Assuming it is a crate like cc printing build script invocations. If cc is going to emit new cargo:: syntax unconditionally, it might want to bump rust-version to 1.77 as well. Alternatively it can have a cargo feature, say 1_77_new_syntax, to enable it and any new build script invocations built upon the new syntax.

[CamJN]

I is me, or I suppose anyone who wants to write a build.rs that emits the old syntax for versions of cargo < 1.77 and the new syntax for versions >= 1.77. In my case the build.rs' are for my *-sys crate, and its safe wrapper crate.

Cargo features must be manually enabled/disabled by users of the crate, if the default doesn't match their setup right? That's not very nice IMO, they shouldn't have to know about the internals of my build.rs and its cargo/rust version compatibility, I'd rather just make it automatic.

As for the use case, there's not really a lot more detail to provide, but I'll re-phrase it a bit in case that's useful:

I want to be able to write a build.rs that can emit the old syntax for old versions of cargo/rust and the new syntax for new versions. I don't want to use the old syntax when the new syntax is available because the new syntax is nice and clearer. However I also don't want to require users of my crate to use rust 1.77 right away, since this cargo syntax is the only thing that I use from 1.77, so I'd like to emit it conditionally, predicated on which version of cargo is going to parse the output of build.rs.

[epage]

“cleaner" syntax that requires hoops to use seems an odd trade off.

The new syntax was created to allow us to more easily add new directives. Using them will require MSRV bumps, so requiring an MSRV bump to use the new syntax seems fairly reasonable.

[weihanglo]

Thanks for the clarification!

This looks like an issue that could be addressed if Cargo provides a crate for build script with that ability. #12432 is the issue tracking it.

Today you could use some helper crates to detect the toolchain version, like https://crates.io/crates/rustversion.

[epage]

imo for #12432, there still wouldn't be reason to support both syntaxes. The situation isn't too different whether others do it or we do it. Instead, we'd likely support the old syntax for any pre-existing directives and new syntax for any new directives until we drop the old syntax from our MSRV.

The main thing I could see doing with version detection is letting users know if a directive is supported so they can fallback to an alternative.

[weihanglo]

The main thing I could see doing with version detection is letting users know if a directive is supported so they can fallback to an alternative.

Yes this is exactly what I meant.

[weihanglo]

Going to propose to close this. We will track the official build script API for version detection in #12432, and people for now can depend on crates like rustversion on crates.io.

[epage]

I concur