logger script

[Kelly O'Hair]

I don't mean to get rid of it entirely, but it is a pain with Windows. I'm just not sure about ever having it
on Windows.

If Magnus comes up with some kind of LOG option to turn it off, that could make sense, right?
Have the automated systems set LOG, developers would get the default. ???

-kto

On Sep 6, 2012, at 6:39 AM, Fredrik Öhrström wrote:

> It is merely a convenience to have stdout and stderr stored in the
> same log file automatically.
> We could just drop the feature altogether, and let the user do
> make > build.log 2>&1 &
> tail -f build.log
> 
> If the logwrapper is default off, then we can just as well drop it
> altogether. Its only value is when the build fails and you did not
> expect it, ie you did not turn on logging.
> 
> Or we could write a short c-program (common/src/logger.c) that does
> the logging thus avoiding the thread and filesystem problems for less
> able platforms.
> 
> //Fredrik
> 
> 2012/9/6 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
>>> 
>>