logger script

[Kelly O'Hair]

I could probably go along with some kind of LOG option here. I had thought of maybe LOG=batch, but
I'll let you design it. ;^)

-kto

On Sep 6, 2012, at 2:05 AM, Magnus Ihse Bursie wrote:

> One problem with the script is that it changes stderr from unbuffered to buffered, which will likely affect output order. I know David Holmes has had issues with this. 
> 
> I have been playing with the idea to extend the LOG argument to make to include control of the use of logging to file. For instance, "make LOG=info,file" or "make LOG=nofile" to enable and disable logging to file, respectively. Or something like that. Then we can decide when logging tofile should be on by default. Maybe it should be off by default, but turned on when setting a different log level (unless explicitely turned off)? That'd sound reasonable to me -- it's likely you only want the log on a file if you're trying to figure out some problem. 
> 
> /Magnus
> 
> 6 sep 2012 kl. 09:49 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
>> Have you seen problems on any other platforms than windows? If it's not working reliably, it will need to be disabled, but preferably only on the unreliable platform.
>> 
>> /Erik
>> 
>> On 2012-09-06 06:14, Kelly O'Hair wrote:
>>> The logger mechanism (common/bin/logger.sh) is clever and everything, but it appears to be
>>> costing us build time (10% on some platforms) and more importantly build stability on windows.
>>> Fancy shell exec logic doesn't seem to be as reliable on windows and just slows it down badly. :^(
>>> 
>>> My tendency is to have it default to being off (e.g. have BUILD_LOG_WRAPPER be empty)
>>> unless we can determine we have a developer doing a build.
>>> Or alternatively we need some kind of 'batch build' setting for build systems.
>>> 
>>> I'm open to ideas here.
>>> 
>>> -kto
>>>