[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    Re: [OE-core] [meta-oe][PATCH 0/3] Log colorizer
From:       "Chris Laplante via lists.openembedded.org" <chris.laplante=agilent.com () lists ! op
Date:       2020-07-29 20:55:33
Message-ID: SN1PR12MB2480AF36B2683F26D1D4777C8B700 () SN1PR12MB2480 ! namprd12 ! prod ! outlook ! com
[Download RAW message or body]

[Attachment #2 (unknown)]

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



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141102): https://lists.openembedded.org/g/openembedded-core/message/141102
Mute This Topic: https://lists.openembedded.org/mt/75836416/4454766
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  [openembedded-core@marc.info]
-=-=-=-=-=-=-=-=-=-=-=-


[prev in list] [next in list] [prev in thread] [next in thread]