[bug-gnu-libiconv] Re: adding version identification to libiconv and libintl

[Bruno Haible]

Hello,

Perry Rapp wrote:
> I pulled the latest gettext via anonymous cvs, and then made a "original" 
> copy
> of it, and ran sh autogen.sh -- presuming I need to autogen my cvs copy
> before I try to configure and build it. (This was to achieve a baseline, 
> before
> I make a second pristine copy & try to put in rc handling.)
> 
> However, I seem to have failed with my process for my baseline.
> 
> I see this in my sh autogen.sh output:
> 
> == BEGIN QUOTE ==
> 
> Don't forget to
>   - add "gnulib-lib/Makefile" to AC_CONFIG_FILES in 
> gettext-runtime/configure.ac
> ,
>   - mention "gnulib-lib" in SUBDIRS in Makefile.am,
>   - mention "-I gnulib-m4" in ACLOCAL_AMFLAGS in Makefile.am,
>   - invoke gl_EARLY in gettext-runtime/configure.ac, right after AC_PROG_CC,
>   - invoke gl_INIT in gettext-runtime/configure.ac.
> 1 out of 1 hunk FAILED -- saving rejects to file /tmp/glSO1312/vasprintf.rej
> gnulib-tool: *** patch file gnulib-local/modules/vasprintf.diff didn't apply 
> cleanly
> gnulib-tool: *** Stop.

Oops. The gettext CVS was not up to date with respect to recent changes in
gnulib. Thanks for reporting it; I've updated it now.

> Frankly, it looks to me like the major portion of the work will be to
> figure out how to work the auto-infrastructure and where to splice
> in rc handling.
>
> The actual script to update version numbers in an rc will be relatively
> easy

Yes, I agree.

> -- I have done something similar, except that my script to update
> rc versions does them in place, and I think a different solution
> would be more appropriate for gettext.

Yes, indeed. In-place modifications of files in CVS are not so welcome. We
prefer to have some files in CVS, which are only changed by hand, and some
generated files, which are not committed into CVS, and which are entirely
managed by the Makefile.am.

> I looked at how the gettext man pages are handled:
> 
> gettext.x has the outline, and then help2man is used to generate
> gettext.1.in, and then a simple sed call puts in the latest version into
> a new file gettext.1. A dependency on root version.sh is used
> to get the last bit rerun if the version is run.
> 
> I think an analogous setup with, e.g., gettext.rc.in being a version
> independent file, and gettext.rc being the one with actual version
> in it, would make sense.

Yes, this is the right way to do it.

> The sed command isn't quite the same, because the VERSION variable
> has the entire version, and it has to be split into numeric pieces for
> an rc file, but that is pretty straightforward (and I already have written
> bash3 script code to do that).

You can do such text manipulations entirely in sed.

> The main question is
> how and whether to handle non-numeric version numbers.
> 
> If a 0.16.3p4 version of gettext is released, that would have to be
> converted to some numeric version in the rc file (e.g., 0, 16, 3, 4,
> or maybe just 0,16,3 with a special build flag). This is because rc files
> are restricted to purely numeric version numbers.

You can limit yourself to maximum three numeric fields and just drop
everything after the first non-numeric character. I.e. assume one of these
patterns:
   [0-9]*\.[0-9]*\.[0-9]*.*
   [0-9]*\.[0-9]*.*
and the last .* part is ignored.

> However, I am not sure whether it is worth the possibly substantial
> amount of help I'd probably need to get through the auto-infrastructure
> to get to the point where I can test putting in the relatively simple
> part of converting, e.g., gettext.rc.in to gettext.rc.

Finding how to put the modification is part of the job. But knowledge about
autoconf and automake is something that you, once learned, can apply to many
packages.

Bruno