On Wed, Aug 05, 2015 at 05:39:50PM -0700, Jason Gerecke wrote: > Sent from the wrong account so the mailinglist rejected it. Re-sending > for the mailinglist's posterity (apologies to Peter & Ping for the > double mail). > > Jason > --- > Now instead of four in the eights place / > you’ve got three, ‘Cause you added one / > (That is to say, eight) to the two, / > But you can’t take seven from three, / > So you look at the sixty-fours.... > > On 8/5/2015 5:20 PM, Jason Gerecke wrote: > > On 8/5/2015 4:06 PM, Peter Hutterer wrote: > >> On Mon, Aug 03, 2015 at 01:45:47PM -0700, Jason Gerecke wrote: > >>> One of the steps that must be completed prior to making a new release is > >>> bumping up the version number in configure.ac. This is an error-prone > >>> process which can be replaced by having configure.ac get the current > >>> version from our "git-version-gen" script. To make a release with this > >>> script in place, simply tag the final commit, run `./autogen.sh` to > >>> update the version numbers, run `make distcheck` to validate the build, > >>> perform any additional testing on the generated tarball, and finally use > >>> the "release.sh" script to push everything up to Sourceforge. > >> > >> heh, funny. for me it's the other way round, I only tag once distcheck etc. > >> all passes :) and adding the version number automatically runs autogen. > >> > >> the release.sh script comes from the xorg one which has seen a fair number > >> of changes since we forked it. it now checks for the top commit to have a > >> tag and (iirc) whether the version number was bumped too. may be worth > >> synching with the xorg one. > >> > >> > > I'll give the xorg one a peek and see what interesting changes have been > > made. Sanity checks like that would be a nice feature, and maybe we can > > do without this patch :) > > > >>> Signed-off-by: Jason Gerecke <jason.gere...@wacom.com> > >>> --- > >>> autogen.sh | 2 +- > >>> configure.ac | 2 +- > >>> git-version-gen | 32 ++++++++++++++++++++++++++++++++ > >>> 3 files changed, 34 insertions(+), 2 deletions(-) > >>> create mode 100755 git-version-gen > >>> > >>> diff --git a/autogen.sh b/autogen.sh > >>> index 354f254..ddde471 100755 > >>> --- a/autogen.sh > >>> +++ b/autogen.sh > >>> @@ -6,7 +6,7 @@ test -z "$srcdir" && srcdir=. > >>> ORIGDIR=`pwd` > >>> cd $srcdir > >>> > >>> -autoreconf -v --install || exit 1 > >>> +autoreconf -v --install --force || exit 1 > >>> cd $ORIGDIR || exit $? > >>> > >>> $srcdir/configure "$@" > >>> diff --git a/configure.ac b/configure.ac > >>> index 6c8488e..b7b514e 100644 > >>> --- a/configure.ac > >>> +++ b/configure.ac > >>> @@ -23,7 +23,7 @@ > >>> # Initialize Autoconf > >>> AC_PREREQ([2.60]) > >>> AC_INIT([xf86-input-wacom], > >>> - [0.30.0], > >>> + m4_normalize(m4_esyscmd([./git-version-gen])), > >> > >> does this need to be added to EXTRA_DIST? also, will this work with > >> builddir != srcdir if you have the path in there? > >> > >> (if distcheck passes, then the answer is yes, so ignore this comment :) > >> > > > > This doesn't need to be added to EXTRA_DIST since its only ever called > > by autoconf. The generated configure file will just have the generated > > version numbers sprinkled throughout.
yeah, but it's missing if you run autoconf in a tarball, which Fedora/RHEL do for example (and other distros too iirc). Just verified that, make dist, unzip and running autoreconf will fail. so looks like this needs to be added to EXTRA_DIST after all. > > As for builddir != srcdir, distcheck runs without issue :) right, distcheck doesn't run autoreconf. but it answers the builddir != srcdir question :) > > > >>> [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], > >>> [xf86-input-wacom]) > >>> AC_CONFIG_MACRO_DIR([m4]) > >>> diff --git a/git-version-gen b/git-version-gen > >>> new file mode 100755 > >>> index 0000000..ca335e2 > >>> --- /dev/null > >>> +++ b/git-version-gen > >>> @@ -0,0 +1,32 @@ > >>> +#!/bin/sh > >>> + > >>> +DEF_VER=UNKNOWN > >>> +TAG_PREFIX="xf86-input-wacom-" > >>> +LF=' > >>> +' > >>> + > >>> +# First see if we're in a git directory and try git-describe, then > >>> +# try the 'version' file if present (included in release tarballs), > >>> +# and finally the default. > >>> +if test -d ${GIT_DIR:-.git} -o -f .git && > >> > >> you don't need this test, git describe will fail if it can't find a git > >> directory anyway > >> > >>> + VN=$(git describe --match "${TAG_PREFIX}*" --abbrev=7 HEAD 2>/dev/null) > >>> && > >>> + case "$VN" in > >>> + *$LF*) (exit 1) ;; > >>> + ${TAG_PREFIX}*) > >>> + git update-index -q --refresh > >>> + test -z "$(git diff-index --name-only HEAD --)" || > >>> + VN="$VN-dirty" ;; > >>> + esac > >> > >> I did not know that you could put case/esac into a test condition. learned > >> something new there, thanks > >> > >>> +then > >>> + VN=$(echo "$VN" | sed -e "s/${TAG_PREFIX}//"); > >>> + #VN=$(echo "$VN" | sed -e 's/-/./g'); > >> > >> drop this line? > >> > >>> +elif test -f version > >>> +then > >>> + VN=$(cat version) || VN="$DEF_VER" > >> > >> wait, what generates the "version" file? am I missing something here? > >> > >>> +else > >>> + VN="$DEF_VER" > >>> +fi > >>> + > >>> +VN=$(expr "$VN" : v*'\(.*\)') > >>> + > >>> +echo $VN > >> > >> can we rename VN to VERSION? would be a lot more obvious to grasp and > >> characters are not at a premium anymore now that we have terabyte > >> harddrives :) > >> > >> Cheers, > >> Peter > >> > > Taking all the git-version-gen comments in one go, this script > > originally comes from [1] and is slightly modified for our use. I'd > > prefer to keep the changes to a minimum so that the script continues to > > resemble upstream as well as its sister version proposed for > > "input-wacom". The first and last comments are upstream decisions, and > > the third and fourth are brought over from input-wacom. > > > > [1]: https://git.kernel.org/cgit/git/git.git/tree/GIT-VERSION-GEN?id=HEAD fair enough, leaving it close to the other one is sensible. Even better would be a comment at the top to link to the kernel one and the input-wacom one so others don't have to guess where it comes from :) Cheers, Peter ------------------------------------------------------------------------------ _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
