bug-gnu-utils
[Top][All Lists]
Advanced

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

Re: burned by Makefile.in.in's $(DOMAIN).pot-update rule


From: Jim Meyering
Subject: Re: burned by Makefile.in.in's $(DOMAIN).pot-update rule
Date: Sat, 12 Jun 2010 11:32:36 +0200

Bruno Haible wrote:
> For a customization to be worth documenting, and worth that every developer
> that uses gettext reads its description and considers to use it, it should
> be more general, that is, applicable to more situations that just yours.
> If the goal is to only handle your particular situation, it can also be done
> without a customization/hook. Would this workaround solve your problem?
>
> --- gettext-tools/po/Makefile.in.in.orig      Sat Jun 12 02:00:07 2010
> +++ gettext-tools/po/Makefile.in.in   Sat Jun 12 01:59:45 2010
> @@ -137,8 +137,16 @@
>
>  # This target rebuilds $(DOMAIN).pot; it is an expensive operation.
>  # Note that $(DOMAIN).pot is not touched if it doesn't need to be changed.
> +# The determination of whether the package xyz is a GNU one is based on the
> +# heuristic whether some file in the top level directory mentions "GNU xyz".
> +# If GNU 'find' is available, we avoid grepping through monster files.
>  $(DOMAIN).pot-update: $(POTFILES) $(srcdir)/POTFILES.in remove-potcdate.sed
> -     if LC_ALL=C grep 'GNU @PACKAGE@' $(top_srcdir)/* 2>/dev/null | grep -v 
> 'libtool:' >/dev/null; then \
> +     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=''; \

It would indeed.  Thank you.

That "fork-and-exec for each file" use of find put me off initially,
but it's limited to top-level files, so it's not prohibitive.

However, if you want to be more economical (and considering
that nearly every gettext user will run this rule, why not?)
you could add one more test to see if "-exec grep ... {} +" works.

For example, this test should be adequate to see if find honors
the newer, POSIX-specified -exec option:

  find Makefile -exec true '{}' +



reply via email to

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