Subject: Re: Unclear what target the output relates to

From: Sergey Matveev <[email-masked]>
Date: Sat, 23 Sep 2023 22:17:10 +0300

Greetings!

*** spacefrogg [2023-09-21 19:12]:
>3. The output of redo has become useless for larger amounts of targets that
>can run in parallel. [...]
>4. In light of no. 3, I have a small feature request: The output of targets
>can be very confusing, because it is unclear at first, what target the
>output relates to.

Do I correctly understand that by "target's output" you mean stderr's
output of the running target? I understand that target's stdout will be
saved in file, but just asking for correct understanding.

By default stderr is not intercepted at all -- if target write something
to it, then it just passes as is transparently to goredo. If you enable
logs keeping (-k/REDO_LOGS=1), then goredo will intercept stderr, saving
it to the file of the corresponding target (.redo/TGT.log), and each
read line is immediately also printed to goredo's stderr, without any
long-term buffering at all too.

But I do not understand how anything can be human readable if you run
many targets in parallel. You can buffer their stderr output in memory
and print only after they are finished -- but in that case you won't see
their real-time instantly written lines. As far as I remember,
apenwarr/redo can show kept logs grouped together and ordered in
chronological order. I made that in goredo's "redo-log -r" command the
same way. You can watch kept logs after the build in a friendly and sane
manner. I think that you need either convenient, properly ordered
(linearized, https://apenwarr.ca/log/20181106) logs viewing, that
"redo-log -r" tries to give, or you need instant unbuffered output just
to understand how that the progress of your build is going further,
nothing is stuck. Imagine hundreds of targets printing to stderr in
parallel, where each line of the output can be produced by different
target.

Maybe (optional) prepending of target's name to each stderr's line may
be enough convenient to watch the progress? I hope I will try to check
its usefulness tomorrow.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967  FD75 CB82 0563 2107 AD8A