[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: Marcus Müller
Subject: Re: [PATCH 1/1] make/po: msgmerge: do not print progress indicators
Date: Wed, 15 Mar 2023 11:27:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

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

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




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

reply via email to

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