bug#29376: automake gnits version check vs. gnulib's git-version-gen?

2018-01-04 Thread Mathieu Lirzin 
Paul Eggert  writes:

> On 11/20/2017 11:44 PM, Bernhard Voelker wrote:
>> So my question: aren't 3-level version strings allowed by the gnits check
>> in combination with gnulib's git-version-gen script?  Do we have to
>> change
>> the strictness from gnits to gnu?
>
> I would think so, unless someone takes the time to change Automake so
> that gnits supports the new format of version strings that
> git-version-gen is generating.

Such change would be welcome.

Basically one would have to adapt the following regexp from automake.

--8<---cut here---start->8---
# This pattern recognizes a Gnits version id and sets $1 if the
# release is an alpha release.  We also allow a suffix which can be
# used to extend the version number with a "fork" identifier.
my $GNITS_VERSION_PATTERN = '\d+\.\d+([a-z]|\.\d+)?(-[A-Za-z0-9]+)?';
--8<---cut here---end--->8---

Ideally with some unit tests.  :-)

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

bug#29376: automake gnits version check vs. gnulib's git-version-gen?

2017-11-22 Thread Paul Eggert 

On 11/20/2017 11:44 PM, Bernhard Voelker wrote:

So my question: aren't 3-level version strings allowed by the gnits check
in combination with gnulib's git-version-gen script?  Do we have to 
change

the strictness from gnits to gnu?


I would think so, unless someone takes the time to change Automake so 
that gnits supports the new format of version strings that 
git-version-gen is generating.

bug#29376: automake gnits version check vs. gnulib's git-version-gen?

2017-11-20 Thread Bernhard Voelker 

At GNU findutils, we're trying to use gnulib's git-version-gen [1]
to derive the version string from the current git commit.

Until now, we've been using a 3-level versioning scheme X.Y.Z, e.g. the
latest tag was 'v4.6.0'.  Now for any non-release commit version
before the next release, 'git-version-gen' determines a version
like e.g. '4.6.0.149-2f6a' for the 149th commit past the v4.6.0 tag;
but the automake gnits check complains:

  ...
  running: AUTOPOINT=true LIBTOOLIZE=true autoreconf --verbose --install 
--force -I gl/m4  --no-recursive
  autoreconf: Entering directory `.'
  autoreconf: running: true --force
  autoreconf: running: aclocal -I gl/m4 --force -I gl/m4 -I m4
  autoreconf: configure.ac: tracing
  autoreconf: configure.ac: not using Libtool
  autoreconf: running: /usr/bin/autoconf --include=gl/m4 --force
  autoreconf: running: /usr/bin/autoheader --include=gl/m4 --force
  autoreconf: running: automake --add-missing --copy --force-missing
  configure.ac:95: installing 'build-aux/compile'
  configure.ac:51: installing 'build-aux/config.guess'
  configure.ac:51: installing 'build-aux/config.sub'
  configure.ac:46: installing 'build-aux/install-sh'
  configure.ac:46: installing 'build-aux/missing'
  configure.ac:195: installing 'build-aux/mkinstalldirs'
  Makefile.am: installing './INSTALL'
  configure.ac:25: error: version '4.6.0.149-2f6a' doesn't follow Gnits 
standards

So my question: aren't 3-level version strings allowed by the gnits check
in combination with gnulib's git-version-gen script?  Do we have to change
the strictness from gnits to gnu?

[1] https://git.sv.gnu.org/cgit/gnulib.git/tree/build-aux/git-version-gen

Thanks & have a nice day,
Berny