[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] git-version-gen: detect untagged revisions

From: Pádraig Brady
Subject: Re: [PATCH] git-version-gen: detect untagged revisions
Date: Tue, 14 Apr 2015 21:34:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 14/04/15 19:43, Mats Erik Andersson wrote:
> Tuesday den 14 April 2015 klockan 11:40 skrev Pádraig Brady detta:
>> On 13/04/15 23:04, Mats Erik Andersson wrote:
>>> The addition of a leading 'g' to the revision hash is mostly a
>>> convenience, but the usability of the patched version applied
>>> to some cloned directory of small depth turned out more pleasant
>>> than I had expected.
>> Pushed.
> This has to be undone, as it breaks 'make dist' due to
> the incomplete (misbehaving?) file 'top/GNUMakefile'.
> There is no problem with a shallow clone, but a corner
> case exists with annotated tags.
> The problem boils down to an issue of tag prefixes,
> namely as soon as it is not the default "v", presumed
> by git-version-gen.
> GNU Inetutils prefers the tag prefix "inetutils-", so we
> use the preparator
>    build_aux/git-version-gen .tarball-version 's/inetutils-/v/;s/_/./g'
> This works correctly for the initial configuration and building,
> but the makefile target 'dist' will invoke 'top/GNUMakefile'
> and when computing '_curr-ver' in line 54, it executes
>    $(_build-aux)/git-version-gen .tarball-version \
>        $(git-version-gen-tag-sed-script)
> where this last sed script is empty. A recursive grep even for
> 'sed-script' gives single hit only, so no value is assigned.
> Hence this renewed call to git-version-gen is not performing
> any prefix masking, whence the tagged version will be rejected
> in the test
>     #### build-aux/git-version-gen: line 161 -- 164
>     case $v in
>        $prefix[0-9]*) ;;
>        *) (exit 1) ;;
>     esac
> since the default 'prefix="v"' is in use, where we would have
> needed "inetutils-".  Unfortunately, this is where my patch
> enters, because of the above "exit 1" my snippet becomes
> active and it prepends the character 'g' and is not able to
> remove the prefix "inetutils-", so is producing a hitherto
> unknown revision string and forces a new call to autoconf,
> where a simple tar-ball build would be expected.
> It hurts to admit it, but the quickest and the best
> solution seems to be the reversal of my well ment patch.
> A whole lot of corner cases must be run through, due
> to unexpectedly large interplay, before one could depend
> on the result. It is the prefix handling and the sed script
> that cause these obscurities.


thanks for the analysis.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]