[Scons-dev] API for warnings and debug messages

[Bill Deegan]

Jason,

Can you push your logging package into a python package, push it to pypi
and then we could depend on it?
I'm not hot on:
a) adding more code
b) adding third party code not in pypi  (ideally we'd pull six in from pypi
and not include it in our source control..)
c) writing custom code where theres a module we could use, unless there's
significant reason to do so (see #1 and #2)

-Bill


On Wed, May 28, 2014 at 10:59 AM, Kenny, Jason L <jason.l.kenny at intel.com>wrote:

>  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>
> 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 (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
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> http://two.pairlist.net/mailman/listinfo/scons-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140528/2fdeaad7/attachment-0001.html>