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