[Top][All Lists]

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

Re: [PATCH 1/1] make/po: msgmerge: do not print progress indicators

From: Bruno Haible
Subject: Re: [PATCH 1/1] make/po: msgmerge: do not print progress indicators
Date: Tue, 14 Mar 2023 22:45:39 +0100

[CCing bug-gettext, since po/Makefile.in.in comes from GNU gettext.]

Marcus Müller wrote in

> msgmerge: do not print progress indicators

This is a reasonable request, but not for the reasons that you state.

> Progress indicators in Makefiles are nearly universally unappreciated

This is an unverifiable claim. Many people think that their personal
opinion is "nearly universal".

> since they completely break compactness of the build log

Compactness of the build log is not a goal. In fact, everyone who uses,
for continuous integration, a machine to which they do not have ssh access
is happy about verbosity and frustrated when a build log is too compact.

> and also make output humanly unparseable if -j>1 is used

'make -jN' always produces garbled output. This is not a reason to
suppress output from various tools. With the same argument, you could
request that compilers no longer emit error messages, but only report
success or failure through a status code.

The real justification is that when this Makefile.in.in was invented,
around 1995, 'msgmerge' was slow, and the machines were slow. A normal
msgmerge run could take 1 minute or 5 minutes.

Nowadays, I ran msgmerge with the largest POT file we have in GNU
(gcc-13.1-b20230212.pot, with gcc-12.1.0.fr.po). It completes in
about 50 seconds of CPU time and 4 seconds of wall clock time.
For most packages, which have POT files smaller than this, msgmerge
thus completes in 1 second or less. This does not require a progress

msgmerge became faster
- through an index-based fuzzy search (msgl-fsearch.c) in 2006,
- through OpenMP parallelization in 2006,
- through processor speedups over the years.
The only case where msgmerge is still slow is when a compendium is in use;
this is a translator use-case, not covered by Makefile.in.in.

So, I agree that in Makefile.in.in, the --quiet option makes sense.

The package's maintainer could already enable this option by setting
MSGMERGE_OPTIONS in the po/Makevars file.

Still, we can enable --quiet also without explicit action from the
package's maintainer. Done through


reply via email to

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