Re: [gettext] several suggestions

[Stepan Kasal]

Hello Bruno,

Bruno Haible (meant to) wrote:
> Stepan Kasal wrote:
> > 1)   -----------------------------------------
> > That means that the variables could be computed in code registered by
> > AC_CONFIG_COMMANDS_PRE.

> These computations are done at the moment when the contents of po/LINGUAS
> in merged into po/Makefile. [...]
> This would mean that when the developer changes his po/LINGUAS, his
> changes are not taken into account until he does "make distclean" and
> "./configure". This is not desirable.

Yes, I agree.  But this can be fixed by adding the following rule to
Makefile.in.in:

$(top_builddir)/config.status: LINGUAS
        cd $(top_builddir) && ./config.status --recheck

> > 2)   -----------------------------------------
> A patch to exploit this $(VAR:.suf=.fux) syntax is welcome.  [...]
> But actually some of the variables have $srcdir in them, and some don't.
[...]
> The value of moving only part of a computation from po.m4 to Makefile.in.in
> is doubtful.

I think that it would be useful to move the full descriptions of the
variables from po.m4 to Makefile.in.in; that's where they are needed.

Makefile.in.in could contain:
--------- snip -----------
# All languages, defined in the file po/LINGUAS
address@hidden@

# Languages to install, ie. those selected by
#       ./configure LINGUAS="..." ...
# (and the fallback ones, see po.m4 for details):
address@hidden@

# This has to be computed by configure:
# SRCDIR_LINGUAS = $(foreach lang, $(ALL_LINGUAS), $(srcdir)/$(lang))
SRCDIR_LINGUAS = @SRCDIR_LINGUAS@

# Add the suffixes:
POFILES       = $(SRCDIR_LINGUAS:=.po)
UPDATEPOFILES = $(LINGUAS:=.po-update)
DUMMYPOFILES  = $(LINGUAS:=.nop)
GMOFILES      = $(SRCDIR_LINGUAS:=.gmo)
CATALOGS      = $(INST_LINGUAS:=.gmo)
--------- snip -----------

Try to look at it with a newcomer's eyes; isn't this transparent?

The long lists are not duplicated in the Makefile, if it is not necessary.
And when they are, the redundancy is clearly explained.

(You said that I should avoid adding new variables, but I think they are
needed, to get more readable Makefile.in.in.)

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

But isn't the redability compromised by the fact that big complicated
chunks of code are duplicated?  Shouldn't we at least define a macro
for the two different `frobbedlang=' computations?

I don't think the code is readable when I have to run diff to make sure
that the assignments which look similar are indeed the same.

[ Oops: sed 's/^[[:blank:]]*//' po.m4|sort -u|grep ^frob
  does the trick.  ;-)  ]

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

I agree with this paragraph, but it's not answer to my question.

Currently, we have two macros in the same file with big code duplication.
Do you mean that when AM_POSTPROCESS_PO_MAKEFILE will go into Automake,
we'll have duplicated code in two distant locations?

I still think that the common code should be moved to a separate macro.
When will AM_POSTPROCESS_PO_MAKEFILE go to Automake, you'll be reminded
you have to decide which of the two projects will be responsible for
that common macro.

Happy hacking,
        Stepan Kasal