[PATCH] configure.ac: Set 'mym4_revision' to 0 if not a git repo

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed Jan 11 01:40:11 CET 2017


On Tue 2017-01-10 09:41:12 -0500, Nathan Rossi wrote:
> ---
> It is possible for the source to not be located in a git repository
> (e.g. source is from a tarball). In which case the git repository
> information is not available. This results in the mym4_revision being an
> empty string however this value is used in BUILD_FILEVERSION where it is
> assumed to be 4 decimal values. Additionally BUILD_REVISION uses this
> value and is also assumed to be non-empty.
>
> In the case of BUILD_FILEVERSION it is used in versioninfo.rc.in, where
> it must be populated as 4 decimal values due to the expected syntax. In
> cases where it is not (e.g. when BUILD_FILEVERSION = '1,7,5,' a syntax
> error is raised.
>
>     windres: versioninfo.rc.in:21: syntax error
>
> This patch changes mym4_revision so that if the 'git rev-parse' returns
> non-zero (e.g. not in a git repository) the value falls back to '0'.
> This propagates as '0' to both BUILD_FILEVERSION and BUILD_REVISION.
>
> Signed-off-by: Nathan Rossi <nathan at nathanrossi.com>
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 31c0d553fa..a3deffa6e9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -39,7 +39,7 @@ m4_define(mym4_version_micro, [0])
>  m4_define(mym4_version,
>            [mym4_version_major.mym4_version_minor.mym4_version_micro])
>  m4_define([mym4_revision],
> -          m4_esyscmd([git rev-parse --short HEAD | tr -d '\n\r']))
> +          m4_esyscmd([(git rev-parse --short HEAD || printf '0') | tr -d '\n\r']))
>  m4_define([mym4_revision_dec],
>            m4_esyscmd_s([echo $((0x$(echo ]mym4_revision[|head -c 4)))]))
>  m4_define([mym4_betastring],


If this is accepted, this change should probably be applied to all the
gpg-related tools that have this kind of git-trickery in configure.ac
(libgpg-error, etc).  I'm currently patching out similar things in
debian so that we get consistent and stable versioning and fewer error
messages in the build logs.

      --dkg



More information about the Gcrypt-devel mailing list