Quantcast

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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Nathan Rossi
---
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 <[hidden email]>
---
 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],
--
2.11.0


_______________________________________________
Gcrypt-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel Kahn Gillmor-7
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 <[hidden email]>
> ---
>  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

_______________________________________________
Gcrypt-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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 <[hidden email]> 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 <[hidden email]>
>> ---
>>  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

_______________________________________________
Gcrypt-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Werner Koch
On Thu, 12 Jan 2017 06:03, [hidden email] said:
> 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

I noticed your pacthed and looked at it.  However, I considere the way
we handle this in gnupg better...

> 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).

Right,  This is easier to maintain because autogen.sh should be
identical for all gnupg related packages,  Meanwhile I have ported this
to libgpg-error but nut yet pushed.  I need to do a few more tests,
though.

Thanks for your work and please have some patience until I can push that
to libgpg-error and other packages.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gcrypt-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

attachment0 (233 bytes) Download Attachment
Loading...