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. Best regards, Mats Erik Andersson, developer of Inetutils.