Building all logger library types?

I see that the logger implementation has multiple variations, but they're compile time options and not run-time. Given that I imagine changing that to a run-time option would be non-trivial, has anyone investigated simply compiling all of the logger libraries variations? One could then choose which variation you want at link-time - I think an improvement.

This is an issue with automated unit test cases, in which we don't want the logger output going to console but would instead like to either make it disappear, or sink it to a stream that we can rifle through when verifying the test output.

Thoughts?
Stephen

Building all logger library types?

On Wednesday 23 April 2008 14:31:26 snrkiwi wrote:
> I see that the logger implementation has multiple variations, but they're
> compile time options and not run-time. Given that I imagine changing that
> to a run-time option would be non-trivial, has anyone investigated simply
> compiling all of the logger libraries variations? One could then choose
> which variation you want at link-time - I think an improvement.
>
> This is an issue with automated unit test cases, in which we don't want the
> logger output going to console but would instead like to either make it
> disappear, or sink it to a stream that we can rifle through when verifying
> the test output.

The only thing you can vary at compile time is:

1. no logging at all (full code size reduction, embedded, production)
2. printf logging (code size reduction, no need for C++ iostream library)
3. iostream logging (largest code size)

These things you don't want to vary at runtime ?

The things you can vary at runtime are:
From the shell:
1. no logging at all ( export ORO_LOGLEVEL=-1 )
2. The loglevel ( export ORO_LOGLEVEL= [1...7] )
From the application code:
3. The loglevels for file and screen
4. Setting the 'standard' ostream
5. getting the log messages line by line (max 1000 stored in cache).

Seems just what you wanted ? See also the rtt/tests/test-runner.cpp file for
how we do it in our unit tests.

Peter

Building all logger library types?

>The only thing you can vary at compile time is:
>
>1. no logging at all (full code size reduction, embedded, production)
>2. printf logging (code size reduction, no need for C++ iostream library)
>3. iostream logging (largest code size)
>
>These things you don't want to vary at runtime ?
>
>The things you can vary at runtime are:
>From the shell:
>1. no logging at all ( export ORO_LOGLEVEL=-1 )
>2. The loglevel ( export ORO_LOGLEVEL= [1...7] )
>From the application code:
>3. The loglevels for file and screen
>4. Setting the 'standard' ostream
>5. getting the log messages line by line (max 1000 stored in cache).
>
>
>
>Seems just what you wanted ? See also the rtt/tests/test-runner.cpp file for
>how we do it in our unit tests.

Got it with 4 above. Are now sinking to a ostringstream through use of setStdStream(). The doc's are slightly confusing though, with

You can disable all logging at compile time by defining OROBLD_DISABLE_LOGGING (not advised for normal usage). This class can log to a console, and/or to a file and/or to an internal buffer which may be emptied by another class. This is decided upon compile time and can not be changed during runtime. Both printf/iostream are supported.

and then later on (the bit that I missed!)

When the application is started, set the displayed loglevel with setLogLevel() with a LogLevel parameter. The default is Warning. Set the desired log streams ( a file or std output ) with logToStream() and setStdStream(). Additionally, an orocos.log which is always logs at log level 'Info'.

The second one lets you know about run-time changes to the stream being logged to, while the first paragraph reads to me as though you can't. Also, "logToStream()" in 2nd para no longer exists.

Thanks again!
S