A common usecase for Libreoffice writer is to act as a headless rendering component.
While the UNO API can be used, the command line options like --convert-to seem to offer a much lower barrier to entry.
Unfortunately; things like #37531 crop up.
Examples of confused users:
* Silent 'failure', users only figuring out they haven't installed libreoffice-writer by accident, etc.
* Others figuring out open instances of libreoffice are getting passed commands; but missing they can specify a per user environment
While --backtrace does exist, it isn't often too helpful.
From IRC discussion:
vmiklos: most logging is done using SAL_INFO() / SAL_WARN(), and those expand to nothing on release builds.
Could a build of libreoffice (particularly what a lot of distros package up as libreoffice-headless) be configured to allow SAL_INFO/SAL_WARN to output to STDOUT/STDERR via a --verbose or --debug type argument if used with --headless.
This would keep the existing silent behaviour for desktop users, but allow semi-technical users to gain some insight if they opt in.
Somewhat similar is Bug #42982 ; which highlights a similar problem in a different area.
The big question is who will deal with the regressions caused by turning --enable-sal-log on by default. The logging is there, but when it's used, the assumption is that performance is not a problem, since in a product build they'll expand to nothing.
So, the way I had imagined it is the various logging functions simply check log level/similar.
While not a null operation, doing
# Start up
log_level = NONE
if params["--headless"] && params["--debug=info"]
log_level = INFO
# On logging
if log_level == NONE
fprintf (stderr, msg)
Doesn't seem like on the face of it that you'd generate huge amounts of unnecessary IO or similar without user buy-in.
If there's a lot of stuff emitted at the wrong log level (ie: more suited to proper DEBUG level logging instead of INFO), though it may produce a bit more memory consumption the implementation would be at the same time providing a wider audience the tools to find this stuff out.
(oh, and to be super clear: I'd be more keen on a specific build - if this is already taken care of as part of the nightlys or similar and as a relative outsider, I've just missed this entirely... that'd be handy to know!)
@Mike, any opinion on this topic ?
The logging in LO is done in places that developers consider useful during the development. At no place any of developers considered the cost of logging when added it in a place (well, I exaggerate a little, but still). So the logging might happen in places called thousands of millions times during e.g. loading of a real-life file. And having a couple of additional comparisons and a couple of indirections in a tight loop might well result in a considerable penalty.
But that is just a speculation. Doers decide; so if anyone wants to give it a try, welcome to dev channel, and please feel free to try to implement the proposal (we would help answering questions, of course) - with necessary testing/profiling. If it turns out to be less problematic than anticipated - why not.
@Mike, thanks for your comment.
Considering the time this issue has been in UNCONFIRMED status and the performance penalty it might cause, let's close it as RESOLVED WONTFIX