Hello David, Thanks for the response.
*>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.* As far as I have understood the problem statement under this project @ https://www.freetype.org/gsoc.html is that the current logging capabilities of FreeType only print the logs on stderr and to scale the FreeType for multiple platforms where something similar to stderr don't exist, there is need to write the logs on files present on the file system. My queries were with respect to this use case. I am sorry I am unable to fully understand your concern in this regard. Can you please provide more insight on this? *>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.* Regarding the library's exploration, it is still in progress and will keep you posted on the same. Some time back I explored zlog library and it was meeting some of our requirements but it was never finalized. Would like to hear from you on this? Also, if possible, can you please let me know which all libraries have already been explored and any documentation around this will help? Initially, we did discussed to change the ftdebug.c to write the logs on file system rather than using an external library but later we concluded that the external library will be more beneficial since they have matured and well tested APIs. *>Do you plan to improve the debugging macros used by FreeType. If so, how exactly?* I am still in the exploration phase and will plan the changes according to the external library... Thanks, Priyesh On Mon, May 18, 2020 at 3:46 PM David Turner <da...@freetype.org> wrote: > > > Le lun. 18 mai 2020 à 10:49, Priyesh kumar <priyeshkku...@gmail.com> 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 >> >
