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

[Nathan Rossi]

On 11 January 2017 at 10:40, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 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.

That was the intention, I did send a patch like this for libgpg-error
at the same time as this (however I think I mucked up the
subscribe/send order and it was not received). I have resent it now.

Other than libgpg-error which tools/libraries should be changed? I am
not particularly familiar with all the related tools/libraries. I did
have a look at some of the gnupg related tools/libraries but they use
differing mechanisms for this process (most use autogen.sh
--find-version).

Thanks,
Nathan