[gettext] several suggestions

[Stepan Kasal]

Hello Bruno and all,
  some time ago I promised you several patches to gettext autoconf macros.
After I looked at it today, I thought I should rather ask you about your
opinion before writing any patch.

All my ideas are about the variables computed in po.m4 (POFILES etc.).
(Some of the following suggestions are in conflict, but let's resolve
that later.)

1)   -----------------------------------------
Why are these variables computed so late?  I think they could be
computed earlier.
They use $srcdir, which is available since AC_INIT.  (I have verified
this in versions 2.13, 2.50, CVS; CVS is still the same as 2.50.)

So the only limitation seems to be that ALL_LINGUAS might be set anywhere
in the body of configure.ac.

That means that the variables could be computed in code registered by
AC_CONFIG_COMMANDS_PRE.  That macro is available at least since 2.50.
(And if we decide later that we need to be compatible with 2.13, I'm
sure we'll find a way to hook just before AC_OUTPUT.)

We'd then call AC_SUBST([POFILES]) etc. in the code given to
AC_CONFIG_COMMANDS_PRE.

Yes, I think AC_SUBST inside AC_CONFIG_COMMANDS_PRE works, and we can
document that, to be safe for the future.

2)   -----------------------------------------
Alexandre has taught me that $(SRCS:.c=.o) is portable.
That means that po.m4 doesn't need to compute so many variables.

Thus you can use:

GMOFILES = $(POFILES:.po=.gmo)
UPDATEPOFILES = $(DUMMYPOFILES:.nop=.po-update)
PROPERTIESFILES = $(CLASSFILES:.class=.properties)
QMFILES = $(POFILES:.po=.qm)
QTCATALOGS = $(CATALOGS:.gmo=.qm)

instead of computing and substituting these variables.

3)   -----------------------------------------
Or you can compute

LANG_LIST=
SRCDIR_LANG_LIST=
for lang in $ALL_LINGUAS; do
  LANG_LIST="$LANG_LIST $lang"
  SRCDIR_LANG_LIST="$SRCDIR_LANG_LIST $srcdirpre$lang"
  ...
done

and use

POFILES=$(SRCDIR_LANG_LIST:=.po)
UPDATEPOFILES=$(LANG_LIST:=.po-update)

etc.

4)   -----------------------------------------
I don't understand why there are so many for-loops.  I'd merge them,
like this:

if test "%UNSET%" != "$LINGUAS"; then
  desiredlanguages="$LINGUAS"
else
  desiredlanguages="$ALL_LINGUAS"
fi
POFILES=  etc.
for lang in $ALL_LINGUAS; do
  POFILES=...
  useit=no
  for desiredlang in $desiredlanguages; do
    case $desiredlang in
    "$lang"*) useit=yes; break;;
    esac
  done
  if test $useit = yes; then
    CATALOGS="$CATALOGS $lang.gmo"
  fi
done

In AM_POSTPROCESS_PO_MAKEFILE, the dependecies for TCLCATALOGS and
CSHARPCATALOGS could also be created in this loop, and accumulated
into, say, $ac_file.dep.tmp.  Later on, we'd
        cat $ac_file.dep.tmp >>$ac_file.tmp

This all would mean that the frobbedlang variables would be computed
only once (frobbedlang_m for msg files and frobbedlang_r for resources,
to be exact).

5)   -----------------------------------------
There is common code in AM_PO_SUBDIRS and AM_POSTPROCESS_PO_MAKEFILE.
Couldn't we keep the common code in a separate macro?
(Yes, the code in AM_POSTPROCESS_PO_MAKEFILE is enhanced, but that
could be solved by m4 conditionals.)

-----------------------------------------
What do you think?

With kind regards,
        Stepan Kasal