logger script

[Fredrik Öhrström]

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
>>
>