Hey guys,
After going through the discussion, I think I am confused about the actual
requirements from the project.
Clearly there is some problem with the current logger, but I think the
requirements which are mentioned on the FreeType's GSoC page and the
requirements which are discussed being here
are different...
Please could you guys guide me with the actual requirements as there is
very little time left for coding to begin...
Thanks
Priyesh
On Thu, May 21, 2020 at 2:07 PM wrote:
> > Armin, could you chime in and add your opinion?
>
> Gladly, sorry for the delay guys!
>
> >> I'm sorry but that doesn't make any sense to me. There is absolutely
> >> no point in making part of FreeType depend on a specific external
> >> logger library at this point. Also we don't even know which library,
> >> or which API. This looks like a solution looking for a problem.
> >>
> >> Also we don't necessarily send logs to stderr, e.g. there are already
> >> several versions of ftdebug.c, i.e. the one under builds/windows/ uses
> >> OutputDebugStringA(), or the one under builds/amiga/ uses KVPrintf(),
> >> etc.. All Werner wants is structured outputs, which can easily be
> >> done in the current code base with minimal refactor of the FT_TRACE
> >> macro implementations.
> >
> > Mhmm, yes and no. For example, if you want to have time stamps in the
> logging
> > output, too, you have to take care of the OS since you are entering
> > platform-specific behaviour. It would be nice if this is completely
> hidden.
>
> Agreed; also in addition, the two biggest things to be improved from my
> perspective:
>
> 1. Dynamic change of desired output log levels
> 2. Dynamic log redirection
>
> I've recently been working on long-running (for days/weeks straight) video
> transcoders, depending on several libraries like FFmpeg, FreeType, ... One
> thing that is 100% needed is to change log levels on the fly (enable more
> logging as things go south) and be able to redirect logs to wherever I want
> them to go, separate for each library, maybe prefixed differently on the
> fly
> (files, memory, ... best case, again, changeable at runtime). I consider
> both things reasonably standard and something I'd love to see in FreeType
> as
> well :)
>
> About external dependencies: everything you don't build yourself leaves
> more time for the things you actually want to build. I do get the concern
> (it's a trade-off) but the question IMO is how easy it is to replace
> dependencies. In terms of an external logging library I imagine it to be
> very easily replaceable should that become interesting at some point.
>
> A few more thoughts about recent messages (didn't chime in since, by the
> point I read it, it was already answered in a way that I agreed with):
>
> - 100% submodule + static linking
>
> - Let's keep using various FreeType macros within the code base and use
> the
> external library mainly for writing out + the filtering / forwarding /
> flexibility part
>
> The biggest upside of an external logging lib IMO is not to care about its
> implementation and cross platform compatibility, just use something that's
> been tried + tested and spend all the more time on the core business of
> font
> rendering. Also provide users of FreeType a way to extract logs in an
> extremely flexible way that does not require users to dig deep into the
> implementation of the codebase in order to write a personalised log
> callback
> function that filters and converts relevant logs and requires users to do
> all sorts of nasty downcasts that really only library implementers are
> comfortable doing.
>
> Just a few thoughts, happy to discuss further :)
>
>
