walles / riff

A diff filter highlighting which line parts have changed
MIT License
232 stars 4 forks source link

git_version breaks building from the github release tarballs #26

Closed 0x5c closed 2 years ago

0x5c commented 2 years ago

This line crashes builds when building riff from the release tarballs since they don't include the git information. https://github.com/walles/riff/blob/7fbec9c86e95003bd15ddeea5394218af9f1b1f1/src/main.rs#L64

The git_version documentation gives multiple options to fallback on the crate version specified in Cargo.toml. Since the crate version in release tarballs should be the same as the git tag, and that git tags are just references to commits, using that would not only not change anything for someone trying to checkout or diff the specific commit corresponding to a build, it would arguably be better since then now it's clearer a build from a release is not just a random unreleased commit from the repo HEAD.

Changing the line to this

const GIT_VERSION: &str = git_version!(cargo_prefix="");

allows the build and sets the version like so

$ riff --version
riff 0.1.0
[...]

This currently has 0.1.0, since that is the crate version declared in Cargo.toml. Of course, setting that properly would require changing the versioning scheme to 3 components instead of two, but that is also a requirement to publish crates.

In short, doing the modification to the git_version macro call and setting the crate version would allow all linux distros and others (https://github.com/walles/riff/issues/20) to package riff without friction and with proper version info.

Side note: If you decide to follow the same versioning/tagging scheme as moar, you'd want cargo_prefix="v" to match the tags.

walles commented 2 years ago

Would it be possible for you to do git clone rather than downloading the tar files?

Just as you noticed, I'm using the version control system for storing version information. If you want a versioned binary it would be super if you could use git clone / git checkout rather than downloading tars!

How would that work for you?

0x5c commented 2 years ago

This is essentially a no-go for most linux distributions. It makes it impossible for packaging systems to host copies of and cache the source used for building the packages, and forces expansive git clone operations anytime a package rebuild is needed (the builder hits a transient failure and needs to retry, the package revision is bumped, someone is working on the package locally and needs to test changes, etc).

walles commented 2 years ago

Done: https://github.com/walles/riff/releases/tag/2.16.2

Tested building from a tar file and it worked and got the Cargo.toml version number.

Also tested building from git, which also got the right version number.

0x5c commented 2 years ago

I can confirm this works well. Thanks!

walles commented 2 years ago

Just out of curiosity @0x5c, did you use this to package riff somewhere?

0x5c commented 2 years ago

Yes, I packaged riff for Voidlinux https://github.com/void-linux/void-packages/blob/master/srcpkgs/riff/template