Thanks for the reply... *>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.* Got that...will keep this in mind while exploring external logging libraries.
*>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.* Yes, I agree that any new library adds to maintenance burden but we already had a discussion around this sometime back. The summary of the discussion was that a well maintained external library comes with mature API's and gets a lot of testing and hence that would be ideal to integrate. Please refer to this mail thread for details( https://lists.nongnu.org/archive/html/freetype-devel/2020-02/msg00025.html ) and let me know in case of any concern. Thanks, Priyesh
