rustyhorde/vergen

Generate cargo instructions at compile time in build scripts for use with the env! or option_env! macros

vergen's Issues

Cross-compilation fails due to transitive `openssl-sys` dependency

v4.0 switched to using git2 instead of running git commands, but unfortunately git2 has a transitive dependency on openssl-sys, which makes it hard to use when cross-compiling for e.g. a Raspberry Pi via https://github.com/rust-embedded/cross.

Travis clones into detached HEAD state

This means the HEAD file is a revision, and will never point to another file. Removing the error condition when the file is a revision and skipping the output is the fix.

Rebuild only when commit changes

I just built my project after including vergen, and then committed those changes to git. Now I wonder what I have to do to make vergen pick up the fact that the git commit changed? I touched the source file and removed the binary, to no avail. rm target -rf helped, but that seems like overkill.

Our build script prints cargo:rerun-if-changed=build.rs, but not doing so triggers a rebuild every time, so that is not a solution either. Isn't there a way that vergen can make cargo rebuild things only if anything actually changed? I tried adding

println!("cargo:rerun-if-env-changed=VERGEN_SHA");

but that did not help.

[offtopic] What is maintainership status of `rl_sys` crate?

crates.io repository link points to a nonexistent repository in this rustyhorde namespace.
It cannot be build with modern Rust (one unsafe is missing), but after fixing the issue it seems to work.
Shall a fork be published to crates.io, shall original rl_sys crate be re-pointed to some new repository or shall the Git repository (possible archived) be restored at original location?

Produce non-git env vars even if `.git` directory is not present

I'd like vergen to provide git env vars when there is a .git directory, but skip them when there is no .git directory.

Actual Output

When I build vergen without a .git directory present, it generates an error.

If I ignore that error, it doesn't generate any env vars at all. Even the env vars that don't depend on git are skipped.

Expected Output

Only the Git config depends on the .git directory - the other env vars can be generated without one.

So I want to be able to write a build script that works regardless of the .git directory:

• if there is no .git directory, generate all the other env vars I've asked for
• when there is a .git directory, generate the Git env vars, as well as the other env vars

Alternative Workaround

If that's not possible, I'd like an easy way to disable the whole Git config. (For example, an "all off" constant for each config.)

Error compiling dependency of enum-iterator-derive

  Compiling enum-iterator-derive v0.8.1
error: there is no argument named `ty`
  --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/enum-iterator-derive-0.8.1/src/lib.rs:62:56
   |
62 |     let ty_doc = format!("Iterator over values of type {ty}");
   |                                                        ^^^^

error: there is no argument named `ty`
  --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/enum-iterator-derive-0.8.1/src/lib.rs:63:40
   |
63 |     let iter_ty = Ident::new(&format!("{ty}EnumIterator"), Span::call_site());
   |                                        ^^^^

error: there is no argument named `ty`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/enum-iterator-derive-0.8.1/src/lib.rs:123:56
    |
123 |     let ty_doc = format!("Iterator over values of type {ty}");
    |                                                        ^^^^

error: there is no argument named `ty`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/enum-iterator-derive-0.8.1/src/lib.rs:124:40
    |
124 |     let iter_ty = Ident::new(&format!("{ty}EnumIterator"), Span::call_site());
    |                                        ^^^^

error: there is no argument named `ty`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/enum-iterator-derive-0.8.1/src/lib.rs:125:46
    |
125 |     let iter_inner_ty = Ident::new(&format!("{ty}EnumIteratorInner"), Span::call_site());
    |                                              ^^^^

error: there is no argument named `i`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/enum-iterator-derive-0.8.1/src/lib.rs:273:40
    |
273 |         let id = Ident::new(&format!("x{i}"), Span::call_site());
    |                                        ^^^

error: there is no argument named `i`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/enum-iterator-derive-0.8.1/src/lib.rs:292:47
    |
292 |             let value = Ident::new(&format!("x{i}"), Span::call_site());
    |                                               ^^^

error: could not compile `enum-iterator-derive` due to 7 previous errors
warning: build failed, waiting for other jobs to finish...
error: build failed

I've recently encountered the above compile error.

vergen fails to build on NetBSD

Is support for BSDs planned? A crate I maintain has just started using vergen to help debug issues by including the commit hash in version information, but unfortunately, vergen is failing to build on NetBSD.

Here's the output of cargo build:

EDIT: just noticed the issue isn't necessarily caused by vergen but by git2, should I file an issue on git2-rs instead?

Compile Error on vergen-7.1.0

I get the following error when compiling vergen-7.1.0. Please let me know if you need more details.

error[E0308]: mismatched types
--> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/vergen-7.1.0/src/feature/si.rs:265:20
|
265 | *user.uid() == process.uid
| ^^^^^^^^^^^ expected u32, found enum Option
|
= note: expected type u32
found enum Option<u32>

For more information about this error, try rustc --explain E0308.
error: could not compile vergen due to previous error

Request to add an option to compile in whether the working directory was dirty

It'd be great to be able to add metadata to a build that recorded whether it was a clean build or not.

For instance, compiling in either 7f9942 or 7f9942-dirty or something.

Compilation speed

I wanted to upgrade vergen in rav1e, but I've noticed they've used a vendored fork, because vergen was slow to compile. It turns out that newer versions of vergen are even slower to compile, by far.

On my machine rav1e's fork takes 6.8s real, 28s user to compile. Official vergen 3 takes 8.3s real, 36s user to compile. vergen 7 takes a whooping 34s real, 4m16s user to compile. This is a lot of big dependencies and a ton of code to compile for a handful of facts that could have been gathered by a small bash script.

Could you consider optimizing vergen for lower overhead and lower compile times? For example, drop the git2 dependency and shell out to command-line git instead. git2 compiles a whole git library from scratch, adds a dependency on a host C compiler (an extra complication when cross-compiling).

anyhow and thiserror pull in the proc-macro machinery, which seems like an overkill. Build-time programs can't use these errors for anything better than a stderr line and an exit code. It could have been Box<dyn Error> or a quick-error macro without involving compiling compiler plug-ins.

Report git dirty state

It'd be cool if we could have the git dirty state available too.

Personally, I like to include the following info in my version strings:

• Git tag (if the repository is on one right now)
• Commit and branch if we are not on a tag
• -dirty postfix if our working directory had changes

Turning into one of these:

v0.2.0
v0.2.0-dirty
2c12d1b
2c12d1b-dirty

Side request: Make it configurable to not use CARGO_PKG_VERSION or use something else (e.g. the commit) as a fallback for the git tag.

environment variable `VERGEN_BUILD_DATE` not defined

I switched to VERGEN_BUILD_TIMESTAMP

See: https://docs.rs/vergen/latest/vergen/#environment-variables

[build-dependencies]
anyhow = "1.0.63"
vergen = { version = "7.4.2", default-features = false, features = ["build", "git"] }

Also, could we not need anyhow ?

Link to documentation dead

Hi!

It seems that the link to the documentation is dead. It returns a 404. See https://github.com/rustyhorde/vergen/blame/7a70330ba3f581244bb4c038812de984665203bb/README.md#L14

Create ConstantsFlags::SEMVER_FROM_GIT_TAG

Problem: I am using vergen to get the version of my software, and i kept on getting the wrong version number from ConstantsFlags::SEMVER, namely "v0.0.1-181-g5c9fcd7", when in my Cargo.toml i specifically name a version of "0.6.5", i.e.

[package]
version="0.6.5"
...

After a search through the source, i discovered that vergen is doing git describe to set the VERGEN_SEMVER variable. Years ago (well, one year really), i had created a tag v0.0.1 and never used tags again. I see in the code that git describe takes precedent. It took me an embarrassing long period of time to find this code (since i totally forgot i made a tag and it wasn't clear that git was the source of the version string), however i propose that you create constants which explicitly name the source of versioning, like ConstantsFlags::SEMVER_FROM_GIT_TAG and ConstantsFlags::SEMVER_FROM_CARGO.

If you consider this a worthy addition, i will be happy to submit a PR for this issue.

Cannot build with rust version 1.57 since commit f322ad588c32e3899482e9a5630e3a6188e7147e

It is not possible to use the latest version with rust 1.57 because msrv_lints is not defined. f322ad5
I think before and since have to use the same version, e.g. 1.58

Handle VERGEN_GIT_* more gracefully if the source is not a git repo

Thanks for making vergen 👍

Followup of #101.

It's quite common for Linux distrubutions to build a package from a source tarball, and not the git repo of the package. In that situation, if the "git" feature is present, the vergen(Config::default()) function in build.rs will Error, and no VERGEN_* variables will be set. Sadly, that also includes vergen variables from other features, like VERGEN_BUILD_* or VERGEN_RUSTC_*, which do not depend on git.

In #101, ignoring the Error vergen() returns and using option_env! later seems to have been okay, probably because the user was only interested in VERGEN_GIT_*. However, ignoring Errors does not feel nice :)

I can think of two ways around this:

• @rapiz1's suggestion: instead of failing completely, simply don't set corresponding Git env vars.
• Or, provide a configuration option "allow-nonexistent" (name TBD) for the Git struct, to keep the old behavior but allow the new.

I'm not sure which I'd prefer, but I'm happy to implement whatever is decided :)

Version 4.2 no longer works on Heroku, while 3.2 did

Not sure what details would be most useful to share, but this is the error message:

Git2(Error { code: -3, klass: 6, message: "could not find repository from \'.\'" })

VERGEN_GIT_SEMVER_LIGHTWEIGHT is not documented

The vergen docs don't mention VERGEN_GIT_SEMVER_LIGHTWEIGHT:
https://docs.rs/vergen/5.1.4/vergen/struct.Git.html#instructions

Because it was missing, I assumed that the Lightweight variant modified the format of VERGEN_GIT_SEMVER, but that's not the case.

Also, I tried looking up the string in the VergenKey enum, but those constants are out of date:
https://github.com/rustyhorde/vergen/blob/master/src/config.rs#L150

SemverKind::Lightweight changes the environment variable

One of the mistakes I always do when enabling vergen (and soon after forgetting about it) is to jump through hoops first discovering the need for SemverKind::Lightweight through #100 (or just trial and error), then I need to look up the environment keys as the env!("VERGEN_GIT_SEMVER") no longer works, find out I need to use env!("VERGEN_GIT_SEMVER_LIGHTWEIGHT").

While looking around, I noticed that the landing page of docs lists an interesting example value for the lightweight version:

vergen/src/lib.rs

Lines 112 to 113 in d827858

	//! | `VERGEN_GIT_SEMVER` | 5.0.0-2-gf49246c |
	//! | `VERGEN_GIT_SEMVER_LIGHTWEIGHT` | feature-test |

Further digging this, the old commit no longer exists, but similar commit 61e560e does. For it, git 2.25.1 reports 5.0.1-2-g61e560e for both git describe with and without --tags.

It seems that it would had helped me use vergen if:

• the VERGEN_GIT_SEMVER name would always stay the same (regardless of lightweight or not)
• by default, the --tags query could probably be made -- I cannot see any downsides, but there of course could be
• the error from git describe operation shouldn't be hidden, instead a hint to disable that variable could be displayed if the branch had no tags

Advice on implementing long version command

I'm using vergen in a number of applications. Ideally I would like to configure all of the build information in build.rs through the vergen Config and then spit out a formatted text table.

Is there some code already written that I can use to do that or do I have to make one myself? I do not want to reimplement the same thing in every CLI tool I build.

Insufficient escaping in code generator

Code generator doesn't escape strings:

https://github.com/rustyhorde/vergen/blob/master/src/output/codegen.rs#L23

Adding quotes around the value is not sufficient - the value could contain quotes or end with backslash, and cause the value to become arbitrary Rust source code.

With the current set of inputs I don't think it's a real vulnerability, but it does increase risk of creating one if some more arbitrary build info was added in the future.

Missing support for git worktree

I am getting the following error trying to use vergen 2.1.1:

error: failed to run custom build command for `miri v0.1.0 (/home/r/src/rust/miri.2)`                                                                                                                              
process didn't exit successfully: `/home/r/src/rust/miri.2/target/debug/build/miri-88c826e4cdc20f81/build-script-build` (exit code: 101)
--- stdout
cargo:rustc-env=PROFILE=debug
cargo:rerun-if-changed=build.rs
cargo:rerun-if-changed=.git/HEAD

--- stderr
thread 'main' panicked at 'Unable to generate vergen constants!: Error(Io(Os { code: 20, kind: Other, message: "Not a directory" }), State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })', libcore/result.rs:1009:5

My build.rs:

extern crate vergen;

use std::env;

fn main() {
    // Forward the profile to the main compilation
    println!("cargo:rustc-env=PROFILE={}", env::var("PROFILE").unwrap());
    // Don't rebuild miri even if nothing changed
    println!("cargo:rerun-if-changed=build.rs");
    // vergen
    vergen().expect("Unable to generate vergen constants!");
}

fn vergen() -> vergen::Result<()> {
    use vergen::{ConstantsFlags, Vergen};

    let vergen = Vergen::new(ConstantsFlags::all())?;

    for (k, v) in vergen.build_info() {
        println!("cargo:rustc-env={}={}", k.name(), v);
    }

    Ok(())
}

New version with fix

After landing 6a2e754, a new version should be created to allow the usage of the latest features without compilation error

Tag for vergen 3.0.4 is missing

There's a version 3.0.4 at https://crates.io/crates/vergen but no corresponding tag here.

dropping Copy impl for Config/Instructions in 5.2.0 breaks semver guarantees

It looks like the Copy trait is no longer derived for Instructions since version 5.2.0, as of this commit:
5f29835

The Copy trait impl is also gone from the documentation:

• 5.1.17 has it: https://docs.rs/vergen/5.1.17/vergen/struct.Config.html
• 5.2.0 doesn't: https://docs.rs/vergen/5.2.0/vergen/struct.Config.html

Dropping a trait impl for a public trait is a SemVer-incompatible change, since it removes an API that was previously there (although implicitly). In this case, because it makes a type that was previously a copy-type a move-type.

I have now seen multiple crates that fail to compile after updating from vergen 5.1.17 to 5.2.0, with errors similar to this one:

error[E0382]: borrow of moved value: `config`
  --> /usr/share/cargo/registry/rd-util-2.1.2/build.rs:11:14
   |
5  |     let mut config = Config::default();
   |         ---------- move occurs because `config` has type `Config`, which does not implement the `Copy` trait
...
8  |     match vergen(config) {
   |                  ------ value moved here
...
11 |             *config.git_mut().enabled_mut() = false;
   |              ^^^^^^^^^^^^^^^^ value borrowed here after move
For more information about this error, try `rustc --explain E0382`.

(error message from build of https://crates.io/crates/rd-util ; also affects builds of all dependent crates)

Git semver is always same as Cargo version

With the following Cargo.toml:

[package]
name = "hello"
version = "1.2.3"
edition = "2021"

[build-dependencies]
anyhow = "1.0"
vergen = { version = "6", default-features = false, features = ["git"] }

and the following git tag:

% git describe --tags
v0.1.0

The VERGEN_GIT_SEMVER is always defined as the crate version:

% cat build.rs
use anyhow::Result;
use vergen::{Config, vergen};

fn main() -> Result<()> {
    let mut config = Config::default();
    vergen(config)?;
    Ok(())
}
% cat src/main.rs
use std::env;

fn main() {
    println!("{}", env!("VERGEN_GIT_SEMVER"));
}
% cargo run
   Compiling hello v1.2.3 (/Users/penberg/src/hello)
    Finished dev [unoptimized + debuginfo] target(s) in 1.00s
     Running `target/debug/hello`
1.2.3

which is unexpected as per documentation:

https://docs.rs/vergen/latest/vergen/#sample-output

The VERGEN_GIT_SEMVER_LIGHTWEIGHT variable does, however, contain the expected output:

% cat build.rs
use anyhow::Result;
use vergen::{Config, vergen, SemverKind};

fn main() -> Result<()> {
    let mut config = Config::default();
    *config.git_mut().semver_kind_mut() = SemverKind::Lightweight;
    vergen(config)?;
    Ok(())
}
% cat src/main.rs
use std::env;

fn main() {
    println!("{}", env!("VERGEN_GIT_SEMVER_LIGHTWEIGHT"));
}
penberg@vonneumann hello % cargo run
   Compiling hello v1.2.3 (/Users/penberg/src/hello)
    Finished dev [unoptimized + debuginfo] target(s) in 1.01s
     Running `target/debug/hello`
v0.1.0

Require sysinfo crate version with the breaking API change

Recently, vergen fixed a breaking change in the sysinfo API.

But the fix only updated the code, and not the sysinfo crate version requirement. So downstream builds that require an older sysinfo version may fail.

Can vergen require a sysinfo version that's greater than or equal to the first version with the new API?

vergen/Cargo.toml

Line 31 in 429f0c2

sysinfo = { version = "0", optional = true, default-features = false }

error: environment variable `VERGEN_GIT_SHA_SHORT` not defined

Support `cargo:rustc-env`

Starting from Rust 1.19 (cargo 0.20.0) (next beta), one may use

println!("cargo:rustc-env=ENVVAR=value");

in the build.rs to define a variable for rustc, allowing code to use

env!("ENVVAR")

vergen could be extended to support this, so user could read the variables without including OUT_DIR.

5.1.2 needs rustc_version>=0.3.1

vergen uses an arbitrary version of rustc_version.
However llvm_version is only available in rustc_version>=0.3.1.

    |
157 |             if let Some(llvmver) = rustc.llvm_version {
    |                                          ^^^^^^^^^^^^ unknown field
    |
    = note: available fields are: `semver`, `commit_hash`, `commit_date`, `build_date`, `channel` ... and 2 others


rustc_version v0.2.3
└── vergen v5.1.2
    [build-dependencies]

https://docs.rs/rustc_version/0.2.3/rustc_version/struct.VersionMeta.html

Relicense under dual MIT/Apache-2.0

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright) and then add the following to
your README:

## License

Licensed under either of
 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, use the following boilerplate (based on that used in Rust):

// Copyright (c) 2016 vergen developers
//
// Licensed under the Apache License, Version 2.0
// <LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0> or the MIT
// license <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. All files in the project carrying such notice may not be copied,
// modified, or distributed except according to those terms.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT/Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @CraZySacX
• @jasonozias

Add support for commit message

If the PR #118 is good enough, I can open another one adding support for the commit message :-)

Please add support for git tag

Perhaps something like VERGEN_GIT_TAG in case the current commit has a git tag? And then option_env! in the code will handle the case when there is no tag.

Dependency explosion in version 4

The recent switch from git CLI to libgit2 caused an explosion in build dependencies, including new non-Rust libraries:

Before (version = "3"):

~/foo> =time cargo build --release
   Compiling autocfg v1.0.1
   Compiling libc v0.2.86
   Compiling ucd-trie v0.1.3
   Compiling bitflags v1.2.1
   Compiling pest v2.1.3
   Compiling num-traits v0.2.14
   Compiling num-integer v0.1.44
   Compiling time v0.1.44
   Compiling semver-parser v0.10.2
   Compiling semver v0.11.0
   Compiling chrono v0.4.19
   Compiling rustc_version v0.3.3
   Compiling vergen v3.2.0
   Compiling foo v0.1.0 (/home/jan/foo)
    Finished release [optimized] target(s) in 5.21s
13.45user 1.53system 0:05.33elapsed 281%CPU (0avgtext+0avgdata 291084maxresident)k
0inputs+117968outputs (4major+356809minor)pagefaults 0swaps

After (version = "4", only git feature):

~/foo> =time cargo build --release
   Compiling libc v0.2.86
   Compiling autocfg v1.0.1
   Compiling pkg-config v0.3.19
   Compiling proc-macro2 v1.0.24
   Compiling unicode-xid v0.2.1
   Compiling version_check v0.9.2
   Compiling syn v1.0.60
   Compiling matches v0.1.8
   Compiling tinyvec_macros v0.1.0
   Compiling log v0.4.14
   Compiling bitflags v1.2.1
   Compiling percent-encoding v2.1.0
   Compiling serde_derive v1.0.123
   Compiling cfg-if v1.0.0
   Compiling serde v1.0.123
   Compiling openssl-probe v0.1.2
   Compiling unicode-bidi v0.3.4
   Compiling tinyvec v1.1.1
   Compiling proc-macro-error-attr v1.0.4
   Compiling proc-macro-error v1.0.4
   Compiling num-traits v0.2.14
   Compiling num-integer v0.1.44
   Compiling form_urlencoded v1.0.0
   Compiling quote v1.0.9
   Compiling unicode-normalization v0.1.17
   Compiling jobserver v0.1.21
   Compiling time v0.1.44
   Compiling cc v1.0.66
   Compiling idna v0.2.1
   Compiling chrono v0.4.19
   Compiling openssl-sys v0.9.60
   Compiling libz-sys v1.1.2
   Compiling libssh2-sys v0.2.21
   Compiling libgit2-sys v0.12.18+1.1.0
   Compiling url v2.2.0
   Compiling vergen v4.0.1
   Compiling enum-iterator-derive v0.6.0
   Compiling getset v0.1.1
   Compiling enum-iterator v0.6.0
   Compiling git2 v0.13.17
   Compiling foo v0.1.0 (/home/jan/foo)
    Finished release [optimized] target(s) in 17.79s
88.06user 9.09system 0:17.91elapsed 542%CPU (0avgtext+0avgdata 387964maxresident)k
3216inputs+488912outputs (5major+1096040minor)pagefaults 0swaps

Rustc commit date and hash does not work when they are unknown

I use vergen in my project Calypso. I recently had a user report to me (though not through GitHub issues) that the build.rs script would not generate the VERGEN_RUSTC_COMMIT_DATE and VERGEN_RUSTC_COMMIT_HASH environment variables when rustc -vV shows them as unknown:

$ rustc -vV
rustc 1.51.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-apple-darwin
release: 1.51.0
LLVM version: 11.0.1

I don't know why they are marked as unknown, but they are. It appears that when these are unknown, they are marked as None in rustc_version::VersionMeta::commit_{hash, date}.
Instead, of being omitted when they are not present, these values should be replaced with another value like "unknown" to prevent this issue from occurring.

Version 2.1 backport is incomplete

The master README says about Version 2.1

Backport of the 3.x.x changes to work on stable until Rust 2018 hits stable.

So I just tried to use generate_cargo_keys, but that does not seem to exist on that branch.

Expose the configuration to override the git repository root

As for now the git repository anchor path (where vergen searches for the .git in parent dirs) is hardcoded to the process's current dir:

vergen/src/gen.rs

Line 69 in 63c5da1

config_from_instructions(config, Some(env::current_dir()?), &mut io::stdout())

According to cargo's docs build script's current dir is set to the source directory of the build script’s package. This leads to the inability to cleanly publish crates that use vergen in build.rs to public crates.io or private registry, since once a crate that uses vergen's git feature in build.rs is downloaded to ~/.cargo/registry/src/.../{crate_name}-{semver_version} directory, we are not able to compile it because there is obviously no git repository at that path.

I propose making the git repo anchor search directory configurable. As for now, we workaround this by setting the current dir of the build script to OUT_DIR which is heuristically ~always the subdirectory of a git repo

Replace `chrono` with `time`?

Would you accept a PR that replaces chono with time?

chrono seems rather unmaintained and has more dependencies than time, plus time is heavily feature-flagged.

feature::git::test::git_describe_works on tagged commit fails

When running the test suite on 862f1e8 (tagged 4.0.1), it fails:

---- feature::git::test::git_describe_works stdout ----
thread 'feature::git::test::git_describe_works' panicked at 'assertion failed: config.cfg_map().get(&VergenKey::Semver).map(|x|\n                                                 x.as_ref().unwrap().to_string())\n    != env::var(\"CARGO_PKG_VERSION\").ok()', src/feature/git.rs:233:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/panicking.rs:92:14
   2: core::panicking::panic
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/panicking.rs:50:5
   3: vergen::feature::git::test::git_describe_works
             at ./src/feature/git.rs:233:9
   4: vergen::feature::git::test::git_describe_works::{{closure}}
             at ./src/feature/git.rs:228:5
   5: core::ops::function::FnOnce::call_once
             at /home/jan/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
   6: core::ops::function::FnOnce::call_once
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/ops/function.rs:227:5

Applying this patch gives some more detail:

diff --git i/src/feature/git.rs w/src/feature/git.rs
index 7a4a05f..065f569 100644
--- i/src/feature/git.rs
+++ w/src/feature/git.rs
@@ -230,12 +230,12 @@ mod test {
         let tags_path = PathBuf::from("testdata").join("tagsrepo");
         add_git_config(ConstantsFlags::all(), Some(tags_path), &mut config)?;
         check_git_keys(config.cfg_map());
-        assert!(
+        assert_ne!(
             config
                 .cfg_map()
                 .get(&VergenKey::Semver)
-                .map(|x| x.as_ref().unwrap().to_string())
-                != env::var("CARGO_PKG_VERSION").ok()
+                .map(|x| x.as_ref().unwrap().to_string()),
+            env::var("CARGO_PKG_VERSION").ok(),
         );
         check_git_instructions(config.cfg_map());
         assert!(config.ref_path().is_some());

---- feature::git::test::git_describe_works stdout ----
thread 'feature::git::test::git_describe_works' panicked at 'assertion failed: `(left != right)`
  left: `Some("4.0.1")`,
 right: `Some("4.0.1")`', src/feature/git.rs:233:9
stack backtrace:
   0: rust_begin_unwind
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/panicking.rs:92:14
   2: vergen::feature::git::test::git_describe_works
             at ./src/feature/git.rs:233:9
   3: vergen::feature::git::test::git_describe_works::{{closure}}
             at ./src/feature/git.rs:228:5
   4: core::ops::function::FnOnce::call_once
             at /home/jan/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
   5: core::ops::function::FnOnce::call_once
             at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/ops/function.rs:227:5

Git repository assumption

I noticed that .git directory is always assumed to be relative to the main cargo workspace file. For monorepos that might not be true - for example, if rust project is a subdirectory of a main repo, .git should be traversed, or queried with something like

git rev-parse --show-toplevel

Thanks in advance for replying!

Documentation for 3.0.4 missing

Might be related to #17 currently the documentation for 3.0.4 is missing https://docs.rs/vergen/3.0.4/vergen/

Build error in version `5.1.12`

I think I have a dependency on vergen in my project. I use it to embed the git sha_256 (hash) into the code so that I can easily check the commit version/info after the project is deployed.

The errors I get are (via my CI build running Ubuntu 18.04 LTS) :

error[E0658]: the `unsafe_op_in_unsafe_fn` lint is unstable
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/vergen-5.1.12/src/lib.rs:184:1
    |
184 | / #![deny(
185 | |     absolute_paths_not_starting_with_crate,
186 | |     anonymous_parameters,
187 | |     array_into_iter,
...   |
291 | |     while_true
292 | | )]
    | |__^
    |
    = note: see issue #71668 <https://github.com/rust-lang/rust/issues/71668> for more information

error[E0710]: an unknown tool name found in scoped lint: `rustdoc::bare_urls`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/vergen-5.1.12/src/lib.rs:307:5
    |
307 |     rustdoc::bare_urls,
    |     ^^^^^^^

error[E0710]: an unknown tool name found in scoped lint: `rustdoc::broken_intra_doc_links`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/vergen-5.1.12/src/lib.rs:308:5
    |
308 |     rustdoc::broken_intra_doc_links,
    |     ^^^^^^^

error[E0710]: an unknown tool name found in scoped lint: `rustdoc::invalid_codeblock_attributes`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/vergen-5.1.12/src/lib.rs:309:5
    |
309 |     rustdoc::invalid_codeblock_attributes,
    |     ^^^^^^^

error[E0710]: an unknown tool name found in scoped lint: `rustdoc::invalid_html_tags`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/vergen-5.1.12/src/lib.rs:310:5
    |
310 |     rustdoc::invalid_html_tags,
    |     ^^^^^^^

error[E0710]: an unknown tool name found in scoped lint: `rustdoc::missing_crate_level_docs`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/vergen-5.1.12/src/lib.rs:311:5
    |
311 |     rustdoc::missing_crate_level_docs,
    |     ^^^^^^^

error[E0710]: an unknown tool name found in scoped lint: `rustdoc::missing_doc_code_examples`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/vergen-5.1.12/src/lib.rs:312:5
    |
312 |     rustdoc::missing_doc_code_examples,
    |     ^^^^^^^

error[E0710]: an unknown tool name found in scoped lint: `rustdoc::private_intra_doc_links`
   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/vergen-5.1.12/src/lib.rs:314:5
    |
314 |     rustdoc::private_intra_doc_links,
    |     ^^^^^^^

error: aborting due to 8 previous errors

Some errors have detailed explanations: E0658, E0710.
For more information about an error, try `rustc --explain E0658`.
error: could not compile `vergen`

I tried cloning this repository and compiling the latest master via cargo build --release and I get a lot of warnings and also the same error(s) on my local machine (Macos Catalina).

Optional git env variables

Follows up #92

Git repository is not always present along with the source code, e.g. downloading source tarball. If feature git is enabled and no git repository is present, the build script using vergen will fail to run and abort the compilation. I think a better way to handle the situation with no available repository is that simply don't set corresponding Git env vars, instead of failing completely. Then by option_env!, the user can determine a fallback method.

Build on docs.rs fails

The documentation on docs.rs failed to build, and it's not available. Build log

Change `COMMIT_DATE` constant

COMMIT_DATE is so awful, will be cool have something like this but with separated time and need to use UTC time.
For example, instead of this need the follow:

• COMMIT_DATE = 2021-02-11
• COMMIT_TIME_UTC = 15:05:53

Consider using git2 instead of executing git process

It would be nice to adapt same approach https://github.com/cstorey/git-build-version uses - reading git metadata using git2 library. This would make building in restricted environment easier, e.g. docker images for cross do not contain git binary.

Rebuild every time

Since I updated to vergen 2.1.0, cargo build does a rebuild every single time, even if nothing changed. I am not yet sure what that is caused by, but my current suspicion is:

cargo:rerun-if-changed=.git/HEAD                                                                                                                                                                                   
cargo:rerun-if-changed=refs/heads/master                                                                                                                                                                           

Notice that the second file does not exist. It should probably be .git/refs/heads/master.

Unable to compile with -Zsanitizer=address

Hello!

It looks like I am not able to compile the crate (and the project which depends on it) when I need address sanitizer.

Reproduction steps:

> rustup default nightly
info: using existing install for 'nightly-x86_64-unknown-linux-gnu'
info: default toolchain set to 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.60.0-nightly (08df8b81d 2022-01-30)
> export RUSTFLAGS=-Zsanitizer=address RUSTDOCFLAGS=-Zsanitizer=address
> cargo build

The output:

   Compiling enum-iterator-derive v0.7.0
   Compiling proc-macro-error v1.0.4
   Compiling thiserror-impl v1.0.30
   Compiling vergen v6.0.2 (/home/kgrech/vergen)
   Compiling libgit2-sys v0.13.1+1.4.2
error[E0428]: the name `nightly_lints` is defined multiple times
  --> build.rs:24:1
   |
19 | fn nightly_lints() {
   | ------------------ previous definition of the value `nightly_lints` here
...
24 | fn nightly_lints() {}
   | ^^^^^^^^^^^^^^^^^^ `nightly_lints` redefined here
   |
   = note: `nightly_lints` must be defined only once in the value namespace of this module

error[E0428]: the name `beta_lints` is defined multiple times
  --> build.rs:32:1
   |
27 | fn beta_lints() {
   | --------------- previous definition of the value `beta_lints` here
...
32 | fn beta_lints() {}
   | ^^^^^^^^^^^^^^^ `beta_lints` redefined here
   |
   = note: `beta_lints` must be defined only once in the value namespace of this module

error[E0428]: the name `stable_lints` is defined multiple times
  --> build.rs:40:1
   |
35 | fn stable_lints() {
   | ----------------- previous definition of the value `stable_lints` here
...
40 | fn stable_lints() {}
   | ^^^^^^^^^^^^^^^^^ `stable_lints` redefined here
   |
   = note: `stable_lints` must be defined only once in the value namespace of this module

error[E0428]: the name `msrv_lints` is defined multiple times
  --> build.rs:46:1
   |
43 | fn msrv_lints() {}
   | --------------- previous definition of the value `msrv_lints` here
...
46 | fn msrv_lints() {
   | ^^^^^^^^^^^^^^^ `msrv_lints` redefined here
   |
   = note: `msrv_lints` must be defined only once in the value namespace of this module

error: /home/kgrech/vergen/target/debug/deps/librustversion-e67a322b869b9b50.so: undefined symbol: __asan_option_detect_stack_use_after_return
  --> build.rs:18:3
   |
18 | #[rustversion::nightly]
   |   ^^^^^^^^^^^

error: cannot determine resolution for the attribute macro `rustversion::nightly`
  --> build.rs:18:3
   |
18 | #[rustversion::nightly]
   |   ^^^^^^^^^^^^^^^^^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

error: /home/kgrech/vergen/target/debug/deps/librustversion-e67a322b869b9b50.so: undefined symbol: __asan_option_detect_stack_use_after_return
  --> build.rs:23:3
   |
23 | #[rustversion::not(nightly)]
   |   ^^^^^^^^^^^

error: cannot determine resolution for the attribute macro `rustversion::not`
  --> build.rs:23:3
   |
23 | #[rustversion::not(nightly)]
   |   ^^^^^^^^^^^^^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

error: /home/kgrech/vergen/target/debug/deps/librustversion-e67a322b869b9b50.so: undefined symbol: __asan_option_detect_stack_use_after_return
  --> build.rs:26:3
   |
26 | #[rustversion::beta]
   |   ^^^^^^^^^^^

error: cannot determine resolution for the attribute macro `rustversion::beta`
  --> build.rs:26:3
   |
26 | #[rustversion::beta]
   |   ^^^^^^^^^^^^^^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

error: /home/kgrech/vergen/target/debug/deps/librustversion-e67a322b869b9b50.so: undefined symbol: __asan_option_detect_stack_use_after_return
  --> build.rs:31:3
   |
31 | #[rustversion::not(beta)]
   |   ^^^^^^^^^^^

error: cannot determine resolution for the attribute macro `rustversion::not`
  --> build.rs:31:3
   |
31 | #[rustversion::not(beta)]
   |   ^^^^^^^^^^^^^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

error: /home/kgrech/vergen/target/debug/deps/librustversion-e67a322b869b9b50.so: undefined symbol: __asan_option_detect_stack_use_after_return
  --> build.rs:34:3
   |
34 | #[rustversion::stable]
   |   ^^^^^^^^^^^

error: cannot determine resolution for the attribute macro `rustversion::stable`
  --> build.rs:34:3
   |
34 | #[rustversion::stable]
   |   ^^^^^^^^^^^^^^^^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

error: /home/kgrech/vergen/target/debug/deps/librustversion-e67a322b869b9b50.so: undefined symbol: __asan_option_detect_stack_use_after_return
  --> build.rs:39:3
   |
39 | #[rustversion::not(stable)]
   |   ^^^^^^^^^^^

error: cannot determine resolution for the attribute macro `rustversion::not`
  --> build.rs:39:3
   |
39 | #[rustversion::not(stable)]
   |   ^^^^^^^^^^^^^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

error: /home/kgrech/vergen/target/debug/deps/librustversion-e67a322b869b9b50.so: undefined symbol: __asan_option_detect_stack_use_after_return
  --> build.rs:42:3
   |
42 | #[rustversion::before(1.58)]
   |   ^^^^^^^^^^^

error: cannot determine resolution for the attribute macro `rustversion::before`
  --> build.rs:42:3
   |
42 | #[rustversion::before(1.58)]
   |   ^^^^^^^^^^^^^^^^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

error: /home/kgrech/vergen/target/debug/deps/librustversion-e67a322b869b9b50.so: undefined symbol: __asan_option_detect_stack_use_after_return
  --> build.rs:45:3
   |
45 | #[rustversion::since(1.58)]
   |   ^^^^^^^^^^^

error: cannot determine resolution for the attribute macro `rustversion::since`
  --> build.rs:45:3
   |
45 | #[rustversion::since(1.58)]
   |   ^^^^^^^^^^^^^^^^^^
   |
   = note: import resolution is stuck, try simplifying macro imports

error: /home/kgrech/vergen/target/debug/deps/libproc_macro_error_attr-022f50c3ea54a790.so: undefined symbol: __asan_option_detect_stack_use_after_return
   --> /home/kgrech/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro-error-1.0.4/src/lib.rs:284:9
    |
284 | pub use proc_macro_error_attr::proc_macro_error;
    |         ^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0428`.
error: could not compile `vergen` due to 20 previous errors
warning: build failed, waiting for other jobs to finish...
error: build failed

Support for branch name

How about adding the ability to pull out the branch name? If this is a feature you'd consider including, let me know, then i will create a PR for you.

I cannot figure out how to use version 5

I tried the example in the docs and as it seems this code does not generate environment variables that are accessible via the env! macro:

use vergen::{Config, vergen};

fn main() -> Result<()> {
  // Generate the default 'cargo:' instruction output
  vergen(Config::default())
}

I reverted to version 4, which does work like this:

use vergen::{vergen, Config, ConstantsFlags};

fn main() {
    let flags = ConstantsFlags::BUILD_TIMESTAMP
        | ConstantsFlags::SEMVER
        | ConstantsFlags::BUILD_DATE
        | ConstantsFlags::SHA_SHORT;
    vergen::gen(flags).expect("Unable to generate the cargo keys!");
}

So version 5 either does not work, or I have no idea how to use it (or is there some info in the docs that I did not find?).