On Wed, May 28, 2014 at 4:17 AM, Gary Oberbrunner ga...@oberbrunner.comwrote:
On Tue, May 27, 2014 at 8:48 PM, William Deegan
b...@baddogconsulting.com wrote:
Gary,
Would it be smart to use the python logging module? (it’s in 2.7 and 3.x)
https://docs.python.org/2/library/logging.html
On Wed, May 28, 2014 at 3:48 AM, William Deegan
b...@baddogconsulting.comwrote:
Gary,
Would it be smart to use the python logging module? (it’s in 2.7 and 3.x)
https://docs.python.org/2/library/logging.html
Less code = good?
Logging is the world's second Python module that needs redesign.
On Wed, May 28, 2014 at 11:53 AM, Kenny, Jason L jason.l.ke...@intel.comwrote:
I would like to know what is wrong with what I propose in Parts?
Maybe nothing -- please send a link or reference.
--
Gary
___
Scons-dev mailing list
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
Gary,
I was under the impression (need to check the code), that you could do:
DefaultEnvironment(tools=[]) in SConstruct and it would prevent any tools
from being initialized and speed SCons startup.
Did I misunderstand?
-Bill
On Wed, May 28, 2014 at 5:40 AM, Gary Oberbrunner
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
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
