[Top][All Lists]

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

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

From: Mats Erik Andersson
Subject: Re: [PATCH] git-version-gen: detect untagged revisions
Date: Tue, 14 Apr 2015 20:43:35 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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 \

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

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.

Best regards,
  Mats Erik Andersson, developer of Inetutils.

reply via email to

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