Export the vcs information as environment variable

[lu-zero]

Problem

Cargo is aware of the vcs information of the tree it is building, would be great to have it exported as environment variable.

Proposed Solution

Populate CARGO_VCS_VERSION, CARGO_VCS_VERSION_LONG with a compact and a long representation of the current tree, e.g. what git describe --tags and the full commit hash.

Notes

No response

[weihanglo]

Thanks for the proposal. I am not quite sure what you mean by "exported as environment variable". Could you clarify what your scenario is and what you expect to see having those environment variables? It could be exposed either for crates, build scripts, external subcommands, or even cargo metadata command. Each of them is a bit different.

If you just want to get those infos in your crate via env! macro, the most common trick you could do is using a build script instruction cargo:rustc-env=VAR=VALUE. Below is an example from Cargo itself:

cargo/build.rs

Lines 47 to 68 in 7bdb969

	fn commit_info() {
	if !Path::new(".git").exists() {
	return;
	}
	let output = match Command::new("git")
	.arg("log")
	.arg("-1")
	.arg("--date=short")
	.arg("--format=%H %h %cd")
	.arg("--abbrev=9")
	.output()
	{
	Ok(output) if output.status.success() => output,
	_ => return,
	};
	let stdout = String::from_utf8(output.stdout).unwrap();
	let mut parts = stdout.split_whitespace();
	let mut next = || parts.next().unwrap();
	println!("cargo:rustc-env=CARGO_COMMIT_HASH={}", next());
	println!("cargo:rustc-env=CARGO_COMMIT_SHORT_HASH={}", next());
	println!("cargo:rustc-env=CARGO_COMMIT_DATE={}", next())
	}

Besides, there is no guarantee that the users has Git installed. A user may use arbitrary VCS tool, though in Cargo the support of Git is way better than others. The other issue is when to extract those infos. We may not want to choke Cargo in every launch to check VCS info (though Cargo already did that to some extent).

[lu-zero]

I assumed that it uses libgit2 for it as built does. I would expect that the information is produced when the crate is compiled.

[weihanglo]

I see. I understand you as trying to get the information at compile time via std::env! for the crate you are building. Given that, can the above build.rs fit your needs?

[lu-zero]

the git-describe-like GIT_VERSION as built is preferable but anything would be nice to have.

[epage]

imo GIT_VERSION only makes sense in specialized library like built, shadow, etc but not in a general tool like cargo because there is no such thing as a GIT_VERSION but that is a specific policy made up of other information.

[epage]

Could you clarify what is expected to be gained by cargo providing this information compared to using libs like built, shadow-rs, or vergen

[lu-zero]

Mainly you avoid building again and again depedencies that are not light.
Cargo already carries libgit2 and already needs to deal with its intricacies to support git dependencies.

I opened this issue after I got enough people complaining after we used built in the latest release of rav1e and it brought in libgit2.

[epage]

Though you've since made libgit2 optional. I also find the use of built in a library to be a bit strange. I can understand more if its being made into an executable (and behind the feature flag for the executable) at which point you are also bringing in other heavy dependencies. For a SO, I can possibly see it though even then, you are not rebuilding those as often.

[lu-zero]

Our downstreams have an userbase of enthusiasts and without knowing the commit hash gets fairly difficult to figure out exactly what went wrong :)

[lu-zero]

At the same time we have distributions that are very happy to use just the release tarballs and want to optimize the build time as much as they could.

My patch making the git components optional should make most people using rav1e happy, but I'd rather move the the fix up in the toolchain since cargo needs to be aware of git already.