mmitch
commented
7 months ago The version number does get generated on every configure run. While this does not change the version during a local edit ... compile ... edit ... compile cycle, it should work for all kinds of packaging scripts.
Now if we somehow could ensure a fresh configure run after every git pull, that would be nice.
mrehkopf
@mrehkopf recently stumbled over gbsplay from Ubuntu showing an empty version string with
gbsplay -V.This might result from using the GitHub-provided release tarball:
When gbsplay is built from a locally cloned git repository, the version number will be set to the output of
git describe, so it refers to current commit from the local git repository.:bulb: Determining the version number only happens once after
make (dist?)clean && make configure. Runninggit pull && maketo get fresh commits does not update the version number. Maybe this needs some work, too…When gbsplay is built from a tarball created by
make dist, the output fromgit describeis used as a version number both in the tarball's filename and as a version number in the sources inside the tarball.When gbsplay is built from either the .zip or .tar.gz that GitHub automatically adds to a release entry (or provides when you click on "download code" instead of cloning the repository), our configure script cannot figure out which version this is:
git describewon't work because there is no git reposity metadata and because the tarball was not created bymake dist, there also is no additional static version data inside the tarball.Possible solutions:
We could remove the default tarballs created by git from the release pages and add our
make disttarballs instead. But this would not fix missing version information in "download code".As a fallback we could try to parse the latest release entry from README.md and declare the version number as
version+Xorversion+?(because we don't know if we are exactly at the released version or some commits after that).I want to investigate the second option via this bug.