Re: [gettext] several suggestions

[Bruno Haible]

Hello Stepan,

Stepan Kasal wrote:
> After I looked at it today, I thought I should rather ask you about your
> opinion before writing any patch.

You're right; save your frustration for other occasions :-)

> 1)   -----------------------------------------
> Why are these variables computed so late?  I think they could be
> computed earlier.

These computations are done at the moment when the contents of po/POTFILES.in
in merged into po/Makefile. It must look at the state of po/POTFILES.in
at the moment it is used, not at a frozen state from the time when
"configure" was run.

> That means that the variables could be computed in code registered by
> AC_CONFIG_COMMANDS_PRE.

This would mean that when the developer changes his po/POTFILES.in, his
changes are not taken into account until he does "make distclean" and
"./configure". This is not desirable.

> 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.

Nice to know: it's portable and it's POSIX. A patch to exploit this
$(VAR:.suf=.fux) syntax is welcome.

> 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.

If you can avoid adding new variables to the po/Makefile.in.in, please do.

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

Basically, each loop computes 1 variable. For maintainability, it is
preferrable to have each variable being computed on its own, rather than
one big 'for' that computes all of them at once. Readability is important
here, speed is not.

> 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).

Likewise; There's no point in mixing a computation for C# and a computation
for Tcl.

> 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?

AM_POSTPROCESS_PO_MAKEFILE is temporary, until of this stuff is handled
by automake. No need to waste time making it perfect.

Bruno