[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: use git-version-gen (was: Re: bison.1 in version control?)
From: |
Eric Blake |
Subject: |
Re: use git-version-gen (was: Re: bison.1 in version control?) |
Date: |
Fri, 18 Jul 2008 20:08:46 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
Joel E. Denny <jdenny <at> ces.clemson.edu> writes:
> >
> > Here's a patch, not yet pushed, that fixes the above. My main goal is to
> > start using git-version-gen for naming versions between releases and to
> > drop our current "PREVIOUS-RELEASE+" scheme. The above changes seemed to
> > help with this.
>
> Also, I need to add the tag v2.3b, but what's the git command to push that
> without pushing my other local tags?
Assuming that origin is your shorthand for savannah's repository:
git push origin refs/tags/v2.3b
>
> > The git-version-gen approach looks fairly robust. However, I dislike that
> > "make" leaves an incorrect version number. Our current scheme merely uses
> > imprecise version numbers instead. Fortunately, "make dist" does correct
> > the version number. Unfortunately, "make install" does not.
This has come up on the gnulib list before, and I suggest re-raising the issue
there. The GNU Coding Standards require that 'make install' do no
recompilation (and running autoconf to change the version string would
generally trigger a recompile). HOWEVER, it also only makes this requirement
on release-quality tarballs, where GNUmakefile/git-version-gen assume
that .tarball-version is present. Therefore, I am of the opinion that making
GNUmakefile trigger a recompile for a 'make install' of a development snapshot
is acceptable.
> >
> > I had to hack bootstrap to remove the "GNUmakefile" entry that gnulib adds
> > to .gitignore. It would be better to patch gnulib to add "/GNUmakefile"
> > instead.
Personally, I don't bother with anchored .gitignore entries. But if you really
want all of bison's entries to be anchored, I'd raise the issue with Bruno;
he's pretty good about patching gnulib-tool to meet user demands.
> > --- a/configure.ac
> > +++ b/configure.ac
> > <at> <at> -19,7 +19,9 <at> <at>
> > # We have strange test case titles, so we need Autoconf 2.61 or better.
> > AC_PREREQ(2.61)
> >
> > -AC_INIT([GNU Bison], [2.3b+], [bug-bison <at> gnu.org])
> > +AC_INIT([GNU Bison],
> > + m4_esyscmd([build-aux/git-version-gen .tarball-version]),
> > + [bug-bison <at> gnu.org])
m4 uses this additional trick, to turn on gnits mode for major releases but use
the more relaxed gnu mode for development:
m4_define([M4_VERSION],
m4_esyscmd([build-aux/git-version-gen .tarball-version]))
m4_bmatch(m4_defn([M4_VERSION]), [^[0-9]], [],
[m4_define([M4_VERSION], [1.9a])])
AC_INIT([GNU M4], m4_defn([M4_VERSION]), address@hidden)
AM_INIT_AUTOMAKE([1.10a subdir-objects dist-bzip2 dist-lzma]
m4_bmatch(m4_defn([M4_VERSION]), [-], [gnu], [gnits]))
Maybe I should document that trick in git-version-gen?
> > AC_DEFINE([PACKAGE_COPYRIGHT_YEAR], [2008],
> > [The copyright year for this package])
This could almost be considered redundant information with the gnulib module
version-etc.
--
Eric Blake
Re: bison.1 in version control?, Akim Demaille, 2008/07/22