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

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

[Marcus Müller]

Progress indicators in Makefiles are nearly universally unappreciated, since they completely break compactness of the build log, and also make output humanly unparseable if -j>1 is used

Signed-off-by: Marcus Müller <marcus_savanah@hostalia.de>
---
 build-aux/po/Makefile.in.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build-aux/po/Makefile.in.in b/build-aux/po/Makefile.in.in
index 6b25f0d916..bd638fb08a 100644
--- a/build-aux/po/Makefile.in.in
+++ b/build-aux/po/Makefile.in.in
@@ -57,7 +57,7 @@ XGETTEXT_ = @XGETTEXT@
 XGETTEXT_no = @XGETTEXT@
 XGETTEXT_yes = @XGETTEXT_015@
 XGETTEXT = $(XGETTEXT_$(USE_MSGCTXT))
-MSGMERGE = @MSGMERGE@
+MSGMERGE = @MSGMERGE@ --quiet
 MSGMERGE_UPDATE = @MSGMERGE@ --update
 MSGMERGE_FOR_MSGFMT_OPTION = @MSGMERGE_FOR_MSGFMT_OPTION@
 MSGINIT = msginit
-- 
2.39.2

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

[Bruno Haible]

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

Marcus Müller wrote in
<https://lists.gnu.org/archive/html/bug-gnulib/2023-03/msg00034.html>:

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

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
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=093929b1d90a98bf0986ded8b629a9d232a85e2e

Bruno

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

[Marcus Müller]

Hi Bruno,

thanks for picking this up! And also, about all the background you're giving; that's much 
appreciated.

On 14.03.23 22:45, Bruno Haible wrote:
> [CCing bug-gettext, since po/Makefile.in.in comes from GNU gettext.]
Thanks :) forwarding a patch is quite an endorsement.
>> msgmerge: do not print progress indicators
> This is a reasonable request, but not for the reasons that you state.
ah; after consideration, that's probably 90% misunderstanding predominately caused by me, 
and 10% difference of opinions. Roughly (87.5% of studies say that most percentages are 
purely made up).
>> Progress indicators in Makefiles are nearly universally unappreciated
> This is an unverifiable claim. Many people think that their personal
> opinion is "nearly universal".

:D Got me, yeah, that is the difference in opinion here. I consider a make run to be 
something that I never observe "interactively", so any progress indicator that ends up in 
my logs is unappreciated /by me/, and not universally. I do feel, however, there's a 
certain wider validity to my claim. Anyhow, not the point: You're right, I don't 
appreciate it, but in this particular case, the dots are practically useless, as you 
notice below.


>> since they completely break compactness of the build log
> Compactness of the build log is not a goal.

So, here's my communication fault: should have said "conciseness". I'm not advocating for 
the omission of detail that might come in handy later, I'm advocating for the omission of 
clutter that's never useful in reading what happens during or after the build has taken place.

> 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.
Sure, that's my usual use case, not even SSH-wise. I read logs, I rarely look at the 
screen while a build I'm mostly expecting to run through or stop at a mistake I made is 
running. Hence my frustration with the dots ;)
>> and also make output humanly unparseable if -j>1 is used
> 'make -jN' always produces garbled output.

Ah, not quite true, is that. In practice, the C-building (and most other) parts of the 
make run are quite well-readable – things that don't output anything don't break output, 
and libc-typical output buffering means that I've never actually seen, even for larger 
compiler warnings and errors, outputs of different programs to be intermingled. Maybe my 
output looks different than yours (would actually be a bit interesting), so for reference, 
[1] is how it looks (prior to patching) to me.

> 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.
Not what I wanted to suggest – warnings and errors are potentially *useful* to read. The 
dots are not. They just tell me "a program I'm using hasn't crashed": Luckily, most 
programs we use to run our builds don't regularly crash, so if my make takes long, then 
well, I (and again, generalizing from that: most people) expect that something's doing 
some work, and "/usr/bin/msgmerge --update --lang=tengwar tengwar.po ringutils.pot" would 
tell me quite precisely where it's stuck (better than the mangled heap of dots that I 
can't attribute to a concrete external program exec).
> 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.
jep, I see that. Also, in 1995 probably looking at make successfully build a large 
internationalized piece of software was a) more exciting and b) less frequently done.
> 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.
Not so dissimilar to my machine; a bit faster than mine.
> For most packages, which have POT files smaller than this, msgmerge
> thus completes in 1 second or less. This does not require a progress
> indicator.
>
> 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.
Nice! Learning something here.
> 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
> https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=093929b1d90a98bf0986ded8b629a9d232a85e2e
>
> Bruno

Thanks!

Best,
Marcus

[1] https://gist.github.com/marcusmueller/7ff98a56a42457397d3cc0f9ac1212f2