Re: Logging Library-GSOC

[Priyesh kumar]

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 <address@hidden> 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 :)