Hi guys, (For Armin){ I have looked into log4c, no doubt it is a powerful logging library and we could use some of it's features to share some logging functionality from FreeType, but I am not sure about it on windows as I am having a hard time compiling it on windows and also I think the pre-built .lib file provided in log4c release @ here <https://sourceforge.net/projects/log4c/files/log4c/1.2.4/mingw-bin/> is also broken/not working, I have to make a .lib file from .dll using dumpbin and lib commands to link log4c with an example and to make it work (-_-)zZ Please help me with this as you have worked with log4c before... Thanks }
After going through log4c, I don't think I have any more options to look onto... If you guys know any more logging libraries, please let me know... Thanks, Priyesh On Mon, Jun 15, 2020 at 10:47 AM Priyesh kumar <priyeshkku...@gmail.com> wrote: > Hi Armin, > > > *>However, I could see how e.g. the usage of `FT_COMPONENT` could be > slightly altered (or an additional macro introduced) if that helps with > moving more functionality into the logger.* > Please, could you provide more information on this... > > Thanks, > Priyesh > > On Sun, Jun 14, 2020 at 3:24 PM <ar...@hasitzka.com> wrote: > >> > No, I haven't thought in that direction as according to the >> requirements least >> > coupling is favorable... >> >> I think (but happy for everyone with other opinions to chime in + >> discuss) at this point the only real hard constraint in that regard is that >> we want to wrap the logger into FreeType specific macros and not expose it >> directly in the core codebase. In addition, `FT_TRACE*` and `FT_ERROR` >> should not be replaced or changed (unless there is a really good reason >> that pretty much everyone agrees on). However, I could see how e.g. the >> usage of `FT_COMPONENT` could be slightly altered (or an additional macro >> introduced) if that helps with moving more functionality into the logger. >> >> As I understand it, parts of this project is to generally enhance tracing >> + logging within FreeType. Apart from platform independent write-out, >> timestamps, custom callbacks, etc ... this _could_, in my opinion, also >> include moving the handling of logging + tracing out of the core codebase >> (if / as much as this is reasonable) as this could open up a lot more >> flexibility down the road (depending on the logging library in question + >> should be discussed separately). I believe that, once we are able to hook >> a specific logger into FreeType with just a few macros, replacing that >> logger might become a reasonably easy task, should requirements change. >> Thus, unless Werner disagrees, I believe it would be interesting to explore >> that option and understand if / how easily this can be done (and to what >> extent). >> >> Best >> Armin >> >>