Ah! I finally have a progress bar that doesn't stall the build!

 - pipe size in Linux is only 8*512=4096 bytes
 - pipe size is not setable
 - when the feeding process spits out data faster than the eating
   process can read it, then the feeding process stalls after 4KiB
   of data sent to the pipe
 - for us, the progress bar would spawn a sub-shell every line,
   and the sub-shell would in turn spawn a 'date' command.
   Which was sloooww as hell, and would cause some kind of a
   starvation: the pipe was full most of the time, and the
   feeding process was stalled all this time.

Now, we use internal variables and a little hack based onan offset
to determine the elapsed time. Much faster this way, but still
CPU-intensive.

1 files changed, 8 insertions, 6 deletions

diff --git a/config/global.in b/config/global.in
index f487a8bf..5d918472 100644
--- a/config/global.in
+++ b/config/global.in
@@ -255,13 +255,15 @@ config LOG_PROGRESS_BAR
     default n
     depends on ! LOG_ALL
     help
-      This option will print a "rotating bar" (/-\|) below the last log line
-      to show work is not stalled.
+      If you say 'y' here, you'll be able to see the elapsed time.
       
-      Available when not in DEBUG log level.
-      
-      WARNING! Very CPU intensive! If you have spare CPU, then you can use it,
-      otherwise, refrain from using it.
+      As a bonus, you'll also get a rotating bar (/-\|) showing you
+      that the build is not stalled (the bar rotates 1/4 every 10 lines
+      of components build log).
+
+      Note that the elapsed time can stall for a little while if a
+      component has long commands, as the elapsed time is only updated
+      each line.
 
 config LOG_TO_FILE
     bool