[Buildroot] [PATCH] utils/brmake: filter output for parallel build

[Buildroot] [PATCH] utils/brmake: filter output for parallel build

[Vincent Stehlé]

When building in parallel with per-package directories
(BR2_PER_PACKAGE_DIRECTORIES=y), brmake output is often garbled:

  2025-10-08T18:39:10 >>> host-dtc 1.7.2 Building
  2025-10-08T18:39:11 checking for stdint.h... >>> host-dtc 1.7.2 Installing to host directory
  2025-10-08T18:39:12 checking for limits.h... >>> host-gmp 6.3.0 Installing to host directory

Remove the spurious string between the timestamp and the ">>>" marker to
fix this.
We need some extra care to preserve the preceding "term bold" special
characters sequence.

Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
---
 utils/brmake | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/utils/brmake b/utils/brmake
index a4b9e7fa71..2a74d58167 100755
--- a/utils/brmake
+++ b/utils/brmake
@@ -12,7 +12,8 @@ main() {
              printf "%(%Y-%m-%dT%H:%M:%S)T %s\n" -1 "${line}"
          done \
          |tee -a br.log \
-         |grep --colour=never -E '>>>'
+         |grep --line-buffered --colour=never -E '>>>' \
+         |sed -E 's/^([0-9T:-]{19}) [[:print:]]*(.*>>> )/\1 \2/'
        )
     ret=${?}
 
-- 
2.51.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] utils/brmake: filter output for parallel build

[Marcus Hoffmann via buildroot]

Hi Vincent!

On 10/9/25 17:28, Vincent Stehlé wrote:
> When building in parallel with per-package directories
> (BR2_PER_PACKAGE_DIRECTORIES=y), brmake output is often garbled:

This has bothered me for sooo long, but I never found out why this is 
going wrong. Do you know why this specifically fails with PPDs (which I 
always enable, so I never knew this was not broken without them)?

> 
>    2025-10-08T18:39:10 >>> host-dtc 1.7.2 Building
>    2025-10-08T18:39:11 checking for stdint.h... >>> host-dtc 1.7.2 Installing to host directory
>    2025-10-08T18:39:12 checking for limits.h... >>> host-gmp 6.3.0 Installing to host directory
> 
> Remove the spurious string between the timestamp and the ">>>" marker to
> fix this.
> We need some extra care to preserve the preceding "term bold" special
> characters sequence.
> 
> Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
> Cc: Yann E. MORIN <yann.morin.1998@free.fr>
> ---
>   utils/brmake | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/utils/brmake b/utils/brmake
> index a4b9e7fa71..2a74d58167 100755
> --- a/utils/brmake
> +++ b/utils/brmake
> @@ -12,7 +12,8 @@ main() {
>                printf "%(%Y-%m-%dT%H:%M:%S)T %s\n" -1 "${line}"
>            done \
>            |tee -a br.log \
> -         |grep --colour=never -E '>>>'
> +         |grep --line-buffered --colour=never -E '>>>' \

Could you explain what --line-buffered does here and why we need this? 
(The man page wasn't too helpful in just specifying "Use line buffering 
on output".

> +         |sed -E 's/^([0-9T:-]{19}) [[:print:]]*(.*>>> )/\1 \2/'
>          )
>       ret=${?}
>   

Best,
Marcus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] utils/brmake: filter output for parallel build

[Vincent Stehlé]

On Thu, Oct 09, 2025 at 07:42:17PM +0200, Marcus Hoffmann via buildroot wrote:
> Hi Vincent!

Hi Marcus,

Thanks for having a look.

> 
> On 10/9/25 17:28, Vincent Stehlé wrote:
> > When building in parallel with per-package directories
> > (BR2_PER_PACKAGE_DIRECTORIES=y), brmake output is often garbled:
> 
> This has bothered me for sooo long, but I never found out why this is going
> wrong. Do you know why this specifically fails with PPDs (which I always
> enable, so I never knew this was not broken without them)?

Yes, this is a limitation of make parallel builds. If we look at the brmake
"pipeline":

    make "${@}" \

At this point we already have all the messages from all the threads, often mixed
on the same line:

  checking for stdint.h... >>> host-dtc 1.7.2 Installing to host directory

The rest of the pipeline just adds the timestamp, copies all the messages to the
br.log and keeps only the messages with the ">>>" markers for the console
output:

    &> >( while read -r line; do
             printf "%(%Y-%m-%dT%H:%M:%S)T %s\n" -1 "${line}"
         done \
         |tee -a br.log \
         |grep --colour=never -E '>>>'
       )

The simplest thing we can do at this point is to cleanup a bit "after the fact".

This is not perfect, but this is far simpler than what aiaiai is doing for
example, with intermediate logfiles and a lock:

https://git.infradead.org/?p=users/dedekind/aiaiai.git;a=blob;f=helpers/aiaiai-make-kernel;h=4338a2764a094f29f4feb38cc3ccdd26336b1ba6;hb=eadfb4d5c88d2dec2842ba8986df42f111d4a7a8#l119

> 
> > 
> >    2025-10-08T18:39:10 >>> host-dtc 1.7.2 Building
> >    2025-10-08T18:39:11 checking for stdint.h... >>> host-dtc 1.7.2 Installing to host directory
> >    2025-10-08T18:39:12 checking for limits.h... >>> host-gmp 6.3.0 Installing to host directory
> > 
> > Remove the spurious string between the timestamp and the ">>>" marker to
> > fix this.
> > We need some extra care to preserve the preceding "term bold" special
> > characters sequence.
> > 
> > Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
> > Cc: Yann E. MORIN <yann.morin.1998@free.fr>
> > ---
> >   utils/brmake | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/utils/brmake b/utils/brmake
> > index a4b9e7fa71..2a74d58167 100755
> > --- a/utils/brmake
> > +++ b/utils/brmake
> > @@ -12,7 +12,8 @@ main() {
> >                printf "%(%Y-%m-%dT%H:%M:%S)T %s\n" -1 "${line}"
> >            done \
> >            |tee -a br.log \
> > -         |grep --colour=never -E '>>>'
> > +         |grep --line-buffered --colour=never -E '>>>' \
> 
> Could you explain what --line-buffered does here and why we need this? (The
> man page wasn't too helpful in just specifying "Use line buffering on
> output".

This tells grep to output its results line by line instead of buffering for too long.
Without this option, brmake output is printed in "bursts", and only from times
to times; not very "live".

You can just remove it and try to see the difference, as this is otherwise
functionally identical.

Best regards,
Vincent.

> 
> > +         |sed -E 's/^([0-9T:-]{19}) [[:print:]]*(.*>>> )/\1 \2/'
> >          )
> >       ret=${?}
> 
> Best,
> Marcus
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] utils/brmake: filter output for parallel build

[Marcus Hoffmann via buildroot]

On 10/10/25 10:01, Vincent Stehlé wrote:
> On Thu, Oct 09, 2025 at 07:42:17PM +0200, Marcus Hoffmann via buildroot wrote:
>> Hi Vincent!
> 
> Hi Marcus,
> 
> Thanks for having a look.

Thanks for the explanations!

> 
>>
>> On 10/9/25 17:28, Vincent Stehlé wrote:
>>> When building in parallel with per-package directories
>>> (BR2_PER_PACKAGE_DIRECTORIES=y), brmake output is often garbled:
>>
>> This has bothered me for sooo long, but I never found out why this is going
>> wrong. Do you know why this specifically fails with PPDs (which I always
>> enable, so I never knew this was not broken without them)?
> 
> Yes, this is a limitation of make parallel builds. If we look at the brmake
> "pipeline":
> 
>      make "${@}" \
> 
> At this point we already have all the messages from all the threads, often mixed
> on the same line:
> 
>    checking for stdint.h... >>> host-dtc 1.7.2 Installing to host directory
> 
> The rest of the pipeline just adds the timestamp, copies all the messages to the
> br.log and keeps only the messages with the ">>>" markers for the console
> output:
> 
>      &> >( while read -r line; do
>               printf "%(%Y-%m-%dT%H:%M:%S)T %s\n" -1 "${line}"
>           done \
>           |tee -a br.log \
>           |grep --colour=never -E '>>>'
>         )
> 
> The simplest thing we can do at this point is to cleanup a bit "after the fact".
> 
> This is not perfect, but this is far simpler than what aiaiai is doing for
> example, with intermediate logfiles and a lock:
> 
> https://git.infradead.org/?p=users/dedekind/aiaiai.git;a=blob;f=helpers/aiaiai-make-kernel;h=4338a2764a094f29f4feb38cc3ccdd26336b1ba6;hb=eadfb4d5c88d2dec2842ba8986df42f111d4a7a8#l119
> 
>>
>>>
>>>     2025-10-08T18:39:10 >>> host-dtc 1.7.2 Building
>>>     2025-10-08T18:39:11 checking for stdint.h... >>> host-dtc 1.7.2 Installing to host directory
>>>     2025-10-08T18:39:12 checking for limits.h... >>> host-gmp 6.3.0 Installing to host directory
>>>
>>> Remove the spurious string between the timestamp and the ">>>" marker to
>>> fix this.
>>> We need some extra care to preserve the preceding "term bold" special
>>> characters sequence.
>>>
>>> Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
>>> Cc: Yann E. MORIN <yann.morin.1998@free.fr>
>>> ---
>>>    utils/brmake | 3 ++-
>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/utils/brmake b/utils/brmake
>>> index a4b9e7fa71..2a74d58167 100755
>>> --- a/utils/brmake
>>> +++ b/utils/brmake
>>> @@ -12,7 +12,8 @@ main() {
>>>                 printf "%(%Y-%m-%dT%H:%M:%S)T %s\n" -1 "${line}"
>>>             done \
>>>             |tee -a br.log \
>>> -         |grep --colour=never -E '>>>'
>>> +         |grep --line-buffered --colour=never -E '>>>' \
>>
>> Could you explain what --line-buffered does here and why we need this? (The
>> man page wasn't too helpful in just specifying "Use line buffering on
>> output".
> 
> This tells grep to output its results line by line instead of buffering for too long.
> Without this option, brmake output is printed in "bursts", and only from times
> to times; not very "live".

Ah, this makes sense, I think I have notices this delay here mostly in 
CI, where sometimes there's no output for minutes. This seems to improve 
that.

This should probably mentioned in the commit message.

> You can just remove it and try to see the difference, as this is otherwise
> functionally identical.
> 
> Best regards,
> Vincent.
> 
>>
>>> +         |sed -E 's/^([0-9T:-]{19}) [[:print:]]*(.*>>> )/\1 \2/'
>>>           )
>>>        ret=${?}

Marcus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] utils/brmake: filter output for parallel build

[Vincent Stehlé]

On Fri, Oct 10, 2025 at 03:47:32PM +0200, Marcus Hoffmann via buildroot wrote:
(grep --line-buffered option)
> Ah, this makes sense, I think I have notices this delay here mostly in CI,
> where sometimes there's no output for minutes. This seems to improve that.

Hi Marcus,

This change of behaviour in your CI messages output rate is an unexpected side
effect!

I think that without any option, grep and sed adapt their output buffering
policy automatically in the same way, depending on what they are connected to (a
terminal or something else).

Now that sed is the last program in the pipeline, I would expect that it would
still buffer its output in your CI case, as grep was doing.

If you fancy, you could try to add the "--unbuffered" option to sed command line
and see if that changes its behaviour in your CI:

  |sed --unbuffered -E 's/^([0-9T:-]{19}) [[:print:]]*(.*>>> )/\1 \2/'

> 
> This should probably mentioned in the commit message.

The intention was to avoid any visible change in term of buffering; sed should
have replaced grep in that sense.

Best regards,
Vincent.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] utils/brmake: filter output for parallel build

[Marcus Hoffmann via buildroot]

Hi Vincent,

On 10/13/25 20:04, Vincent Stehlé wrote:
> On Fri, Oct 10, 2025 at 03:47:32PM +0200, Marcus Hoffmann via buildroot wrote:
> (grep --line-buffered option)
>> Ah, this makes sense, I think I have notices this delay here mostly in CI,
>> where sometimes there's no output for minutes. This seems to improve that.
> 
> Hi Marcus,
> 
> This change of behaviour in your CI messages output rate is an unexpected side
> effect!
> 
> I think that without any option, grep and sed adapt their output buffering
> policy automatically in the same way, depending on what they are connected to (a
> terminal or something else).
> 
> Now that sed is the last program in the pipeline, I would expect that it would
> still buffer its output in your CI case, as grep was doing.

I see. So either sed is behaving slightly differently from grep here or 
this was just the placebo effect at work here. :)

> 
> If you fancy, you could try to add the "--unbuffered" option to sed command line
> and see if that changes its behaviour in your CI:
> 
>    |sed --unbuffered -E 's/^([0-9T:-]{19}) [[:print:]]*(.*>>> )/\1 \2/'
> 

I tested this side-by-side (with or and without unbuffered sed) now and 
this definitely makes a significant difference in output reactivity in 
our gitlab CI. But as you said, this is kind of unrelated to the actual 
change you wanted to make. (I have another comment on that as well, but 
I'll send that in a separate email).

>>
>> This should probably mentioned in the commit message.
> 
> The intention was to avoid any visible change in term of buffering; sed should
> have replaced grep in that sense.

I see, maybe still mentioning why this is needed for grep here, might be 
helpful for readers of the code/commit message.>
> Best regards,
> Vincent.
Best,
Marcus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] utils/brmake: filter output for parallel build

[Marcus Hoffmann via buildroot]

On 10/9/25 17:28, Vincent Stehlé wrote:
> When building in parallel with per-package directories
> (BR2_PER_PACKAGE_DIRECTORIES=y), brmake output is often garbled:
> 
>    2025-10-08T18:39:10 >>> host-dtc 1.7.2 Building
>    2025-10-08T18:39:11 checking for stdint.h... >>> host-dtc 1.7.2 Installing to host directory
>    2025-10-08T18:39:12 checking for limits.h... >>> host-gmp 6.3.0 Installing to host directory
> 
> Remove the spurious string between the timestamp and the ">>>" marker to
> fix this.
> We need some extra care to preserve the preceding "term bold" special
> characters sequence.
> 
> Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
> Cc: Yann E. MORIN <yann.morin.1998@free.fr>

Reviewed-by: Marcus Hoffmann <buildroot@bubu1.eu>
Tested-by: Marcus Hoffmann <buildroot@bubu1.eu>

> ---
>   utils/brmake | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/utils/brmake b/utils/brmake
> index a4b9e7fa71..2a74d58167 100755
> --- a/utils/brmake
> +++ b/utils/brmake
> @@ -12,7 +12,8 @@ main() {
>                printf "%(%Y-%m-%dT%H:%M:%S)T %s\n" -1 "${line}"
>            done \
>            |tee -a br.log \
> -         |grep --colour=never -E '>>>'
> +         |grep --line-buffered --colour=never -E '>>>' \
> +         |sed -E 's/^([0-9T:-]{19}) [[:print:]]*(.*>>> )/\1 \2/'
>          )
>       ret=${?}
>   

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] utils/brmake: filter output for parallel build

[Marcus Hoffmann via buildroot]

Hi Vincent,

On 10/9/25 17:28, Vincent Stehlé wrote:
> When building in parallel with per-package directories
> (BR2_PER_PACKAGE_DIRECTORIES=y), brmake output is often garbled:
> 
>    2025-10-08T18:39:10 >>> host-dtc 1.7.2 Building
>    2025-10-08T18:39:11 checking for stdint.h... >>> host-dtc 1.7.2 Installing to host directory
>    2025-10-08T18:39:12 checking for limits.h... >>> host-gmp 6.3.0 Installing to host directory
> 
> Remove the spurious string between the timestamp and the ">>>" marker to
> fix this.

After testing this change for a few days now, I have two slightly odd 
things to report:

I have seen the following thing happen once during a CI run, where 2 of 
the lines where truncated in the middle of the timestamp. I have looked 
through a bunch of build logs now but haven't seen this again, so not 
sure if that's an actual problem we need to care about

2025-10-14T10:28:01 >>> [something]
202
2025-10-14T10:28:01 >>> [more things]
[... lots of stuff in between]
2025-10-1


And secondly, also in CI:
The "Done in Xmin Ys" text that is printed in the end is still always 
displayed in the middle of a line during the end of the build output:

2025-10-17T08:52:28 >>> owfs 3.2p4 Installing to staging directory
2025-10-17T08:52:29 >>> owfs 3.2p4 Fixing libtool fDone in 7min 37s
iles
2025-10-17T08:52:30 >>> owfs 3.2p4 Installing to target
2025-10-17T08:52:38 >>> python-pydantic-core 2.33.2 Installing to target
2025-10-17T08:52:52 >>> e2fsprogs 1.47.2 Building
[...]

Adding the --unbuffered argument to the final sed call, fixes that.


> We need some extra care to preserve the preceding "term bold" special
> characters sequence.
> 
> Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
> Cc: Yann E. MORIN <yann.morin.1998@free.fr>
> ---
>   utils/brmake | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/utils/brmake b/utils/brmake
> index a4b9e7fa71..2a74d58167 100755
> --- a/utils/brmake
> +++ b/utils/brmake
> @@ -12,7 +12,8 @@ main() {
>                printf "%(%Y-%m-%dT%H:%M:%S)T %s\n" -1 "${line}"
>            done \
>            |tee -a br.log \
> -         |grep --colour=never -E '>>>'
> +         |grep --line-buffered --colour=never -E '>>>' \
> +         |sed -E 's/^([0-9T:-]{19}) [[:print:]]*(.*>>> )/\1 \2/'
>          )
>       ret=${?}
>   


Marcus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] utils/brmake: filter output for parallel build

[Vincent Stehlé]

On Fri, Oct 17, 2025 at 04:12:34PM +0200, Marcus Hoffmann wrote:
> Hi Vincent,
..
> After testing this change for a few days now, I have two slightly odd things
> to report:
> 
> I have seen the following thing happen once during a CI run, where 2 of the
> lines where truncated in the middle of the timestamp. I have looked through
> a bunch of build logs now but haven't seen this again, so not sure if that's
> an actual problem we need to care about
> 
> 2025-10-14T10:28:01 >>> [something]
> 202
> 2025-10-14T10:28:01 >>> [more things]
> [... lots of stuff in between]
> 2025-10-1
> 
> 
> And secondly, also in CI:
> The "Done in Xmin Ys" text that is printed in the end is still always
> displayed in the middle of a line during the end of the build output:
> 
> 2025-10-17T08:52:28 >>> owfs 3.2p4 Installing to staging directory
> 2025-10-17T08:52:29 >>> owfs 3.2p4 Fixing libtool fDone in 7min 37s
> iles
> 2025-10-17T08:52:30 >>> owfs 3.2p4 Installing to target
> 2025-10-17T08:52:38 >>> python-pydantic-core 2.33.2 Installing to target
> 2025-10-17T08:52:52 >>> e2fsprogs 1.47.2 Building
> [...]
> 
> Adding the --unbuffered argument to the final sed call, fixes that.

Hi Marcus,

Thank you for the extensive testing!

What you described is a valid reason I think to add the --unbuffered argument to
sed; I will respin a v2.

Best regards,
Vincent.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] utils/brmake: filter output for parallel build

[Yann E. MORIN via buildroot]

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

Vincent, Marcus, All,

On 2025-10-17 16:39 +0200, Vincent Stehlé spake thusly:
> On Fri, Oct 17, 2025 at 04:12:34PM +0200, Marcus Hoffmann wrote:
> > I have seen the following thing happen once during a CI run, where 2 of the
> > lines where truncated in the middle of the timestamp. I have looked through
> > a bunch of build logs now but haven't seen this again, so not sure if that's
> > an actual problem we need to care about
[--SNIP--]
> > And secondly, also in CI:
> > The "Done in Xmin Ys" text that is printed in the end is still always
> > displayed in the middle of a line during the end of the build output:
> > 
> > 2025-10-17T08:52:28 >>> owfs 3.2p4 Installing to staging directory
> > 2025-10-17T08:52:29 >>> owfs 3.2p4 Fixing libtool fDone in 7min 37s
> > iles
> > 2025-10-17T08:52:30 >>> owfs 3.2p4 Installing to target
> > 2025-10-17T08:52:38 >>> python-pydantic-core 2.33.2 Installing to target
> > 2025-10-17T08:52:52 >>> e2fsprogs 1.47.2 Building
> > [...]
[--SNIP--]
> What you described is a valid reason I think to add the --unbuffered argument to
> sed; I will respin a v2.

For what it's worth, I've locally extensively tweaked and almost
rewritten brmake over the years since I initially submitted the original
one, and which addresses all the issues I've seen mentionned in this
thread (but I only skimmed over0.

Basically, it inverses the filtering and the tee, tee-ing before
filtering. It also uses a bash coproc to beter catch-and-terminate the
process in case of Ctrl-C (but it is not 100% perfect).

The most important thing is that is forces -Otarget (unless -O was
already specified on the command line) to group per-target output and
avoid mixing output of multiple recipes.

It got quite a bit more complex, of course, but hey... :-]

With this, I can no longer observe any mangled or mixed-up line.

Feel free to properly submit it if you like it better. ;-)

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[-- Attachment #2: brmake --]
[-- Type: text/plain, Size: 3098 bytes --]

#!/bin/bash

trap_ctrl-c() {
    if [ -n "${MAKE_PID}" ]; then
        printf '\rInterrupted, waiting for jobs to finish...\n' >&6
        kill -INT ${MAKE_PID}
        wait ${MAKE_PID}
        exit ${?}
    fi
}

disp_time() {
    local start="${1}"
    local S h m s

    if [ "${BRMAKE_ABS_TIME}" ]; then
        printf '%(%T)T' -1
    else
        S=$((${EPOCHSECONDS:-$(date +%s)}-start))
        h=$((S/3600))
        m=$(((S%3600)/60))
        s=$((S%60))
        [ "${h}" -eq 0 ] || printf '%d:' "${h}"
        printf '%02d:%02d' "${m}" "${s}"
    fi
}

main() {
    local ret start dir_found dir O log_file outsync

    start=${BR_START:-${EPOCHSECONDS:-$(date +%s)}}

    # Crude parsing to find the directory with the .config
    dir="$(pwd)"
    dir_found=false
    outsync=-Otarget
    for i in "${@}"; do
        ${dir_found} && { dir="${i}"; dir_found=false; continue; }
        case "${i}" in
        (-C|--directory)    dir_found=true;;
        (-C*)               dir="${i#-C}";;
        (--directory=*)     dir="${i#--directory=}";;
        (O=*)               O="${i#O=}";;
        (-O|-O*)            outsync=;;
        esac
    done

    if [ -n "${O}" -a -e "${O}/.config" ]; then
        log_file="${O}/br.log"
    elif [ -z "${O}" -a -e "${dir}/.config" ]; then
        log_file="${dir}/br.log"
    else
        # No .config, don't log, and let Buildroot do its magic (i.e., whine)
        exec make "${@}"
    fi

    {   coproc LOGGER \
        {
            printf '\r%s' "$(disp_time "${start}")"
            IFS="${CR}"
            tee -a "${log_file}" \
            |sed -u -r -e '/^.{4}(>>> .+)/!d; s//\1/' \
            |while true; do
                if read -r -t 0.25 line; then
                    printf '\r%s %s%s%s\n' \
                        "$(disp_time "${start}")" \
                        "${BRMAKE_PREFIX:+${BRMAKE_PREFIX} }" \
                        "${prev}" \
                        "${line}"
                    disp_time "${start}"
                    prev=""
                elif [ ${?} -gt 128 ]; then
                    prev="${prev}${line}"
                    printf '\r%s' "$(disp_time "${start}")"
                else
                    break
                fi
            done
            exit 0
        } >&3
    } 3>&1

    trap trap_ctrl-c INT

    exec 5>&1 16>&1 6>&2 >&${LOGGER[1]} 2>&1 4>&1
    exec 16>&-
    ${MAKE:-make} ${outsync} "${@}" 2>&1 &
    MAKE_PID="${!}"
    wait ${MAKE_PID}
    ret="${?}"
    MAKE_PID=""
    exec >&5 2>&6 4>&-

    # bash seems to have issues closing an fd when it is an indexed-array
    # expansion, while it has no problem opening it (see above).
    eval exec "${LOGGER[1]}>&-"
    wait ${LOGGER_PID}

    printf '\r%s %s>>> ' "$(disp_time "${start}")" "${BRMAKE_PREFIX:+${BRMAKE_PREFIX} }"
    if [ "${BRMAKE_ABS_TIME}" ]; then
        printf 'Done in %s' "$(BRMAKE_ABS_TIME= disp_time "${start}")"
    else
        printf 'Finished at %(%T)T' -1
    fi
    if [ ${ret} -ne 0 ]; then
        printf ' (error %d)' ${ret}
    fi
    printf '\n'

    return ${ret}
}

CR="
"

main "${@}"

[-- Attachment #3: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot