On Mon, May 18, 2020 at 9:28 AM David Turner <da...@freetype.org> wrote: > > > > Le lun. 18 mai 2020 à 09:03, Priyesh kumar <priyeshkku...@gmail.com> a écrit : >> >> Hey, >> I wanted to ask that after selecting desirable external library how should I >> proceed: >> 1. Should I stick to the existing debugging facility in which filtering of >> log messages is based on debug level comparisons of various FreeType's >> components and only use the external library to write log messages to file >> instead of stderr? >> OR >> 2. Most external libraries provide some log levels capabilities themselves, >> so, should I think in direction of utilizing those. In case yes, then how >> should that be utilized? >> > I recommend not baking details of the logging library into the rest of > FreeType whenever possible. One thing that can be done is to send structured > logs from FreeType, i.e. instead of FT_Message() sending a string to whatever > log, the function could instead send a (component, level, message) tuple, > which would allow filtering externally (in the log library, through whatever > means are necessary). Also something useful when tracing is scoping traces > with start/stop events, but that would require new FT_TRACE_XXX() macros, so > should probably be considered a stretch goal. Just keep this in mind if you > intend to modify that part of the code. > >> >> In the 2nd case, FreeType's logger will completely depend on the external >> library, and developers will also need to learn some new information to use >> the logger. And In the worst-case scenario, if the external library drops >> some functionality, we will need to make amendments to the logger. >> > I still don't know what the benefits of these external logging libraries will > be. Can you clarify what are we supposed to gain from this in practical > terms? Every dependency we add to the library becomes a maintenance burden, > so I would be in favor of the least coupling possible. >
what about dlopen this external log lib ? Vincent Torri