bug-bison
[Top][All Lists]
Advanced

[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






reply via email to

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