Well the code is in Parts and is sort of integrated in to it and custom to deal with SCons issues. I can look at pulling it out in to a separate package. I don’t see why as a subsystem it could not be separated from Parts as a whole. The only issues is how throwing and reporting of Error are handled in Parts and or Scons as currently I throw a SCons error type when an Error message happens ( and a flags is set to do this).
As for as more code. We looking to remove stuff like subprocess code in SCons? Also are we looking at trying to make SCons install via pip? So using third part options is viable? Keep in mind the whole point of Parts is to make SCons better. I would think we want to think about how to refactor the code to make it less, and worry less about more code if it does something that is missing in SCons. Of course maybe we want to think about the design as a whole. For example, do we want to fix the –interactive mode up ( requires new code) or do we want to make it so this is a addin, making SCons more of an engine. Jason From: Scons-dev [mailto:[email protected]] On Behalf Of Bill Deegan Sent: Wednesday, May 28, 2014 4:42 PM To: SCons developer list Subject: Re: [Scons-dev] API for warnings and debug messages 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 <[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>] 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 <[email protected]<mailto:[email protected]>> 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 _______________________________________________ Scons-dev mailing list [email protected]<mailto:[email protected]> http://two.pairlist.net/mailman/listinfo/scons-dev
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
