On Thu, 2012-06-07 at 12:31 +0200, Lukas Zeller wrote:
> Hi Andris,
>
> thanks for the patch. However, the SMLERRPRINTFX() macro, like all
> debug output macros across the entire library, is supposed to output a
> linefeed by itself. It also actually does so in my builds of
> libsynthesis, so if the LFs are missing in your output, it must be
> something along the path from SMLERRPRINTFX() to the actual output
> function.
>
> I think the problem is in the CONSOLEINFO_LIBC shortcut output mode
> Patrick added this February (13ff1e4149 (logging + Linux: enable
> console output)), where CONSOLEPRINTF() is mapped to
> fprintf(stderr,...) without adding a LF. In my (iOS) build this new
> mode is not used, but output ends in a plain puts(), which does add
> the LF.
Indeed. I wasn't aware of that convention when adding the code.
> diff --git a/src/sysync/sysync_debug.h b/src/sysync/sysync_debug.h
> index 61d4cdd..68dce5e 100755
> --- a/src/sysync/sysync_debug.h
> +++ b/src/sysync/sysync_debug.h
> @@ -110,7 +110,7 @@ TDebugLogger *getDbgLogger(void);
> // Because a lot of libs log to stderr, include a unique prefix.
> // Assumes that all printf format strings are plain strings.
> #define CONSOLEPUTS(m) CONSOLE_PRINTF_VARARGS("%s", (m))
> -#define CONSOLE_PRINTF_VARARGS(_m, _args...) fprintf(stderr, "SYSYNC " _m,
> ##_args)
> +#define CONSOLE_PRINTF_VARARGS(_m, _args...) fprintf(stderr, "SYSYNC " _m
> "\n", ##_args)
> #define CONSOLEPRINTF(m) CONSOLE_PRINTF_VARARGS m
> # else // CONSOLEINFO_LIBC
> #define CONSOLEPUTS(m) ConsolePuts(m)
I've added that to my repo and also refined the CONSOLEINFO_LIBC code a
bit: instead of always using stdio, it lets the app override the actual
function.
I'm adding that because I get quite a bit of error output from the
SyncML TK which seems to be harmless. Some of reporting inside
libsynthesis duplicates my own reporting. So I'd rather disable console
printing dynamically and only enable it when the log level in
SyncEvolution is sufficiently high.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
