Le lun. 18 mai 2020 à 10:49, Priyesh kumar <[email protected]> a écrit :
> 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. > > I'm afraid, this thread doesn't seem to answer any of my concerns. Also in the last message you said you would explore logging libraries, and I would be curious about the results, i.e.: - Can you give one *concrete example* of an actual logging library that would be useful for FreeType developers for development purposes. Because I failed to find one. - What would be the actual benefits to using an external logging library really? The only thing I can think of is using structured debug messages (i.e. sending a (component, level, message) tuple instead of a string to whatever receives the log messages, to allow better filtering). But we can easily refactor ftdebug.c to do that, with a default implementation that prints to stderr / , and a debug-only API to inject a custom sink callback at runtime. Only then can we decide to optionally provide a sink that depends on a specific third-party library, as an option. - Do you plan to improve the debugging macros used by FreeType. If so, how exactly? Note that the quality of the logging library(ies) has nothing to do with this. I would rather not introduced a surperfluous dependency to the build. - David > Thanks, > Priyesh >
