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 > >
