[bug-gettext] $(DOMAIN).pot-update's search for --package-name arg

[Jim Meyering]

Hi Bruno,

The $(DOMAIN).pot-update rule in Makefile.in.in goes to some length to
determine whether to use
address@hidden@ or
--package-name='GNU @PACKAGE@'

$(DOMAIN).pot-update: $(POTFILES) $(srcdir)/POTFILES.in remove-potcdate.sed
        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 'GNU @PACKAGE@' /dev/null '{}' ';' 2>/dev/null; \
             else \
               LC_ALL=C grep 'GNU @PACKAGE@' $(top_srcdir)/* 2>/dev/null; \
             fi; \
           } | grep -v 'libtool:' >/dev/null; then \
          package_gnu='GNU '; \
        else \
          package_gnu=''; \
        fi; \

The above is significantly improved over what is provided by
gettext-0.18.1, since it skips large files.  Thanks!

However, what do you think about skipping the find/grep and
libtool filter altogether when @PACKAGE_NAME@ starts with GNU?
i.e. prefix the test with this:

        if case '@PACKAGE_NAME@' in GNU*) true;; *) false;; esac || \

Then, neither find nor grep, nor the kludgey libtool: filter need
come into play for most GNU packages.

An alternative would be to simply use @PACKAGE_NAME@, if it is nonempty.

Why do I bother to suggest this?
Because I have once again hit the large-file problem while
using the gettext-0.18.1-provided Makefile.in.in.
It caused "make distcheck" to fail in a hard-to-diagnose manner
in my grep working directory.  Reported here:

    http://thread.gmane.org/gmane.comp.gnu.grep.bugs/4539

The short-term fix is simply not to create files that trigger
such misbehavior.  Obviously, I'd like something longer-term.
My current work-around (already used in coreutils' bootstrap.conf)
is fragile because it involves substituting part of po/Makefile.in.in
that changes after gettext-0.18.1 (adding the "find" use above).

By the way, note that currently the value of package_gnu is computed
unconditionally, while it is used only with new-enough gettext.  Thus,
technically, its computation could be moved "down" into the sole
case where it is used.