Re: [Bug-gnulib] gnulib vs gettext

[Bruno Haible]

Karl Berry writes:
> I installed gettext 0.12.1 on my development system today and found some
> discrepancies with gnulib.

Yes I wanted to let people test gettext a while before I merge the
macros into gnulib.

I've now made the upgrade:

2003-05-30  Bruno Haible  <address@hidden>

        * modules/gettext: Add files m4/nls.m4 and m4/po.m4.
        * config/config.rpath: Upgrade to gettext-0.12.1.

lib:
        * config.charset: Upgrade to gettext-0.12.1 and libiconv-1.9.1.
        * localcharset.h: Likewise.
        * localcharset.c: Likewise.
m4:
        * gettext.m4: Upgrade to gettext-0.12.1.
        * nls.m4: New file, from gettext-0.12.1.
        * po.m4: New file, from gettext-0.12.1.
        * progtest.m4: Upgrade to gettext-0.12.1.

> 1) config.rpath was updated in gettext 0.12.1, but the gnulib version
>    remained the same (from 2002).  I updated it in gnulib and added it
>    to config/srclist.txt.

I prefer a manual update. Some gettext releases need a while of
testing until I trust them.

> 2) mkinstalldirs had an older version in gettext 0.12.1 than in gnulib.
>    Bruno, can you update gettext or do you want me to mail bug-gettext?
>    (Or do you see some problem with the gnulib version?)

The master source of mkinstalldirs is in automake, not gettext. Please
report a bug to bug-gnu-gettext only if this old version of
mkinstalldirs causes malfunctioning. Remember that using older
versions of automake _can_ be a source of reliablity :-)

> 3) gettext's m4/ulonglong.m4 was at serial 2, but gnulib has serial 3.
>    (Just adds a comment and corrects a user message.)  Bruno, same
>    question here.

I'll look at it.

> 4) gnulib/m4/inttype_h.m4, stdint_h.m4, and uintmax_t.m4 all have the
>    gettext version in their serial line.  If we're going to consider
>    those files as sourced from gettext, fine, I will add them to
>    srclist.txt.

No these file don't originate in gettext. The comment in the serial
line is only a reminder which packages use the macro. Feel free to add
coreutils-x.y, diffutils-x.y, findutils-x.y etc. there when you make a
release of them. And remove all the release tags when you bump the
serial version, of course.

The purpose of the comments is to give an indication who is
responsible for a .m4 file. Well, maybe these comments are not
necessary now that every module lists its .m4 files and every module
has a formal maintainer? I don't know.

Bruno