[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.
Done,
thanks for the analysis.
Pádraig