make cout destination output fully customizable...

[knoepfel]

This issue has been migrated from https://cdcvs.fnal.gov/redmine/issues/23217 (FNAL account required)
Originally created by @ron003 on 2019-09-03 22:03:34

---

In artdaq_mfextensions, we have created a plugin which allows the user to define the format of the messages using a
simplified printf style format specification. The code allows, for example,
format_string:"%%MSG-%s %N: %d %T %r %f:%u\n%m\n%%MSG"
to cause messages to be printed out in the default (3-line) format.
It would be nice if this plugin could be incorporated into the base messagefacility as an alternate "cout" destination.
The plugin code can be viewed at:
https://cdcvs.fnal.gov/redmine/projects/mf-extensions/repository/git/revisions/develop/entry/mfextensions/Destinations/OTS_mfPlugin.cc
Note: this code works with message from all the Log* methods. As far as I can tell, the Log{Problem,Print,Verbatim,Trace,...} methods
work with the full filename such that we have added a feature where a configurable portion of the filename will be printed.

[knoepfel]

Comment by @knoepfel on 2019-09-04 14:57:02

---

In what way does the supported 'timestamp' pattern not meed your need? See 'art --print-description mfPlugin:cout' and look for the 'timestamp' parameter.

Also, messagefacility's plugin system is there specifically so users can implement their own destinations, as you have done. Is there a reason why OTS_mfPlugin should become part of the general distribution?

[knoepfel]

Comment by @ron003 on 2019-09-04 15:50:53

---

timestamp formatting is not an issue.
The example OTS_mfPlugin allows complete control over both what_info is printed and what_order the info is printed in.
It allows for the standard 3 line formatting but does not (currently) support automatic line breaks in the message text.
When I configure the OTS_mfPlugin to produce the exact output that the built-in cout type produces, the messages seem to
take 15 to 20% longer. Although I don't have proof, I'm guessing this is b/c of plugin mechanism overhead.
So, IMHO, you should consider including it because of the complete (i.e. better) configuration ability (currently, partial output configurability is provided but it does not seem possible to opt out of printing filename:linenum) along with efficiency gains over the plugin.