search

beehive-lab / mambo

A low-overhead dynamic binary instrumentation and modification tool for ARM (both AArch32 and AArch64 support) and RISC-V (RV64GC).
Apache License 2.0
323 stars 69 forks source link

makefile: allow overriding GIT_VERSION #61

Closed umarcor closed 2 years ago

umarcor commented 3 years ago

Currently, git describe produces 651c7665-dirty because the tags in this repo are unannotated tags. This PR adds option --tags in order to take those into account and produce 2-21-g651c7665-dirty instead.

lgeek commented 2 years ago

This is working as intended. In this repository we don't maintain release tags. I believe the only tags are for the revisions used in some of our papers, and we don't want to show those as part of the software release versions as they're not very relevant.

Do you have a use case where you need something like this in a fork or for some other project?

umarcor commented 2 years ago

Fair enough. I thought that tags 1 and 2 were meaningful indeed. I do understand why you don't want those to be shown in the version string.

I believe the only tags are for the revisions used in some of our papers, and we don't want to show those as part of the software release versions as they're not very relevant.

May I suggest that you tag them with an explicit name such as TACO2016 or VEE20? That would make it easier for readers of the paper to find the commits matching the article, and arbitrary visitors would better understand the context of those tags.

Do you have a use case where you need something like this in a fork or for some other project?

I'm actually interested in the other two fields: the difference in number of commits (21 above), and the hash of the commit. The hash of the commit allows to uniquely identify a version, which is desirable. It also allows to know whether it's coming from the main/upstream or from somewhere else. However, the commit alone is not enough for easily telling apart which of two versions is more recent. The tag-diff prefix allows doing so.

I'd be good with e.g. replacing the release number with the branch name (and omit it if it's master/main). My concern is whether it's possible to have some integer (incremental) number without using any tag as a reference. Can we always get the difference taking the initial commit of the repo?

umarcor commented 2 years ago

After a second thought, I updated this PR to allow users to override GIT_VERSION. It does not make much sense to write complex git statements in the makefile. Overriding GIT_VERSION allows any consumer of the codebase to apply their own versioning logic through make GIT_VERSION=myver clean all.

For the record, git rev-list HEAD --count returns an integer, but I don't find it desirable to concat multiple git calls in the makefile.