From: "Chris Laplante" <chris.laplante@agilent.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [meta-oe][PATCH 0/3] Log colorizer
Date: Wed, 29 Jul 2020 20:55:33 +0000 [thread overview]
Message-ID: <SN1PR12MB2480AF36B2683F26D1D4777C8B700@SN1PR12MB2480.namprd12.prod.outlook.com> (raw)
In-Reply-To: <edc83a1a101292425dce9dd1c9df51d6b8db8e7a.camel@linuxfoundation.org>
Hi Richard,
> This looks interesting. Could we add something to the manual about how to
> use it and maybe a test for it as well please?
Halfway through writing the tests, and I realized LOG_COLORIZER_SUPPRESS_COLORIZED_OUTPUT doesn’t quite work. I wrote a test recipe with a do_compile that purposely fails with a compile error, to check whether color diagnostics work.
But I'm getting color text printed out after "Log data follows: " which is knotty's response to the bb.build.TaskFailed.
This is because of some code of _exec_task in build.py.
581 try:
582 for func in (prefuncs or '').split():
583 exec_func(func, localdata)
584 exec_func(task, localdata)
585 for func in (postfuncs or '').split():
586 exec_func(func, localdata)
587 except bb.BBHandledException:
588 event.fire(TaskFailed(task, fn, logfn, localdata, True), localdata)
589 return 1
590 except Exception as exc:
591 if quieterr:
592 event.fire(TaskFailedSilent(task, fn, logfn, localdata), localdata)
593 else:
594 errprinted = errchk.triggered
595 logger.error(str(exc))
596 event.fire(TaskFailed(task, fn, logfn, localdata, errprinted), localdata)
597 return 1
The color output is coming from line 595. The CommandFailed exception from bb.process.run carries with it the stdout of the process, which in this case has color text.
I think at this point, I question whether I should just integrate with bit BitBake bake directly. If I were to do that, I could also fix the limitation of .color and .nocolor logs not having output from pre/postfuncs. I propose this:
log-colorizer.bbclass:
1. Responsible for setting up CFLAGS
2. Responsible for passing the appropriate flags/environment variables depending on build system in use (for example, the little bit of code I have targeting CMake).
BitBake:
1. Ensure progress handlers only see filtered output. At the BitBake level I can just do this directly and not mess around with proxy progress handlers.
2. Create a "--suppress-color" flag that filters out ANSI escape sequences from the console and the task log
3. Maintain the .nocolor and .color versions of the logs. Though I'm not sure how I'd keep LOG_COLORIZER_TASKS-like functionality (which only writes .nocolor/.color logs for tasks we actually expect to produce color output). Maybe I should do it automatically based on whether any escape sequences are detected.
The user would still be responsible for INHERIT'ing log-colorizer globally or per-recipe.
What do you think?
Thanks,
Chris
prev parent reply other threads:[~2020-07-29 20:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 1:35 [meta-oe][PATCH 0/3] Log colorizer Chris Laplante
2020-07-28 1:35 ` [meta-oe][PATCH 1/3] lib/oe/log_colorizer.py: add LogColorizerProxyProgressHandler Chris Laplante
2020-07-28 1:35 ` [meta-oe][PATCH 2/3] base.bbclass: make oe.log_colorizer available in global context Chris Laplante
2020-07-28 1:35 ` [meta-oe][PATCH 3/3] log-colorizer.bbclass: add new class Chris Laplante
2020-07-28 2:02 ` ✗ patchtest: failure for Log colorizer Patchwork
2020-07-28 15:50 ` [OE-core] [meta-oe][PATCH 0/3] " Richard Purdie
2020-07-28 19:24 ` Chris Laplante
2020-07-29 14:29 ` Chris Laplante
2020-07-29 20:55 ` Chris Laplante [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SN1PR12MB2480AF36B2683F26D1D4777C8B700@SN1PR12MB2480.namprd12.prod.outlook.com \
--to=chris.laplante@agilent.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.