[Scons-dev] API for warnings and debug messages

[Kenny, Jason L]

I agree it look complex, but it is not that bad…

It mostly about taking output from different sources and putting it together allowing for coloring, no mangled text ( as we get with raw scons and a –j based build). Each part is simple and does a simple thing. What I was suggesting here was more of a view to add a SCons.api.output module that has some sort of error_msg(), warning_msg() etc… This allow an easy way to standardize output formats. For verbose and or debugging messages it can be very useful to allow for a filter logic.

What I have is simple in this.

You can say –verbose=<type>,<type1> on the commandline and only verbose_msg(“type”,”message”) will print. This makes for a simple API to output stuff. And control what gets outputted vs the dump everything and grep logic that is common.

With this, what it does under the covers can change to do different things as found to be useful. Having an API that is clear I feel is more useful.

Jason


From: Scons-dev [mailto:scons-dev-bounces at scons.org] On Behalf Of Gary Oberbrunner
Sent: Wednesday, May 28, 2014 11:56 AM
To: SCons developer list
Subject: Re: [Scons-dev] API for warnings and debug messages



On Wed, May 28, 2014 at 12:40 PM, Kenny, Jason L <jason.l.kenny at intel.com<mailto:jason.l.kenny at intel.com>> wrote:
It was part of the document I sent out on how I deal with steaming of stuff.

There is an internal API that I provide.
The main interface function are defined in parts.api.output.py<http://parts.api.output.py> (attached as tigris is messed up at the moment, need to move to bitbucket…). these functions call stuff in a Parts reporter for coloring/ log mapping. For this discussion this could just call print() internally instead of all the other stuff I have.

The document talks a little about the main structure… it could be improved. But the main value I have with it is that it hides python 2 and 3 issues. It allows me a way to filter message, and it makes extra virtual streams that can be nice to separate, stuff like verbose and trace/debug can be nice separation. It also allow for a extendable logger. I have a simple html, text and rtf logger at the moment.

Let me know if there any questions

Just skimmed the document.  The parts logger seems very complex in design, perhaps even more so than python's logger module (which has loggers, handlers, formatters, and more).  It does a lot, but it seems focused on handling output from subcommands rather than simple debug tracing, so we can get some visibility into SCons's guts.  Let me put together my simple trace stuff for review and see what you think.

--
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140528/5c268867/attachment.html>