[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-gettext] update-po is too touchy

From: Akim Demaille
Subject: [bug-gettext] update-po is too touchy
Date: Tue, 9 Oct 2018 06:58:16 +0200


In Bison, at some point distcheck started to fail, because it
was try to update the srcdir’s bison.pot from the builddir’s
one, because they were different.  The difference was that one
had its headers about ‘GNU bison’ while the other one had ‘bison’.

The reason is that update-po looks for ‘GNU @address@hidden to decide
whether to include ‘GNU’ or not in the header.

In Bison I follow the common practice that ‘Bison’ denotes the
package, and ‘bison’ denotes the tool.  So there’s no occurence
of ‘GNU bison’, but many occurrences of ‘GNU Bison’.

It just happens that I had log files of distcheck in my tree.
And guess what: in the distcheck traces you can see the shell
snippet from gettext’s Makefile which is looking for ‘GNU bison’,
so since then, update-po found such an occurence, in the log files.
But in the distcheck’s tree, this log file is not there, so ‘GNU'
is no longer part of the header.

So I suggest that, to cope with the classical convention on
the package names, po/Makefile.in.in now uses ‘grep -i’ instead
of simply grep.

Like this:

$(DOMAIN).pot-update: $(POTFILES) $(srcdir)/POTFILES.in remove-potcdate.sed
        package_gnu="$(PACKAGE_GNU)"; \
        test -n "$$package_gnu" || { \
          if { if (LC_ALL=C find --version) 2>/dev/null | grep GNU >/dev/null; 
then \
                 LC_ALL=C find -L $(top_srcdir) -maxdepth 1 -type f \
                               -size -10000000c -exec grep -i 'GNU @PACKAGE@' \
                               /dev/null '{}' ';' 2>/dev/null; \
               else \
                 LC_ALL=C grep -i 'GNU @PACKAGE@' $(top_srcdir)/* 2>/dev/null; \
               fi; \
             } | grep -v 'libtool:' >/dev/null; then \
             package_gnu=yes; \
           else \
             package_gnu=no; \
           fi; \
        }; \


Of course, it would be nice too, if git seems to be present,
to use ‘git grep’, and then fall back to grep.  It would also
have saved me from this issue.  This grep is really too permissive
and catches whatever is in the tree.  Or restrict it to configure.ac,
Makefile.am (or Makefile.in), README.

reply via email to

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