RE: Logging Library-GSOC

[armin]

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