Re: [ft-devel] Logging library proposal

[armin]

Hehe I was just preparing a detailed answer myself to bridge the gap until you 
have time to answer ... but you beat me ;)

Also: hi Yash, welcome to FreeType :)

>>> Anyways, a simple solution to an inaccessible stderr is to print log 
>>> messages directly into a file.  Our code will work independently of 
>>> whether stderr is accessible or not.
>
> Yes.

Seems sensible.

>> Can you elaborate on what are your exact targets in this project?
>> Does the project only aim for "platforms with inaccessible stderr"?
>> Can you explain me some difficulties we may face?  If you feel zlog 
>> is suitable for this project, I want to start contributing to 
>> freetype in gsoc as well.

Do you plan to contribute as part of GSoC or outside of it?  For GSoC you can 
expect reasonable mentoring to ease you into working with/on FreeType but 
outside of that you're a bit more on your own due to lack of personnel ;)  
Please mind that participating GSoC organisations are only revealed later in 
February and, while unlikely, there is a chance that FreeType will not be 
chosen to take part this year.

> The target is to improve and streamline FreeType's debugging capabilities.  
> Please have a look at file
>
>   https://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/docs/DEBUG
>
> to see how debugging works.
>
> Armin, can you chime in?  You probably know better than me what could be
> improved.  And would you be willing to act as a mentor for this GSoC project?

Exactly, the main idea is to get rid of the current logging system and 
completely replace it with a state-of-the-art logger that is being developed 
"out of house".  The idea is to simply "use" that logger and not to care about 
developing/debugging/adjusting/fixing it.

I think it all starts with carefully evaluating the current logger (it's 
definitely not to be underestimated;  it has quite a few nifty features!) and 
make sure that everything stays possible one way or another _OR_ have good 
reasons for dropping/replacing features.  It's not just about adding a nice 
logger but about finding something that convinces Werner to drop his own 
brainchild and switch over to the new one ;)

That being said, a big downside of the current logger (in my opinion, Werner 
will disagree probably) is it's lack of "ease of use".  I, personally, think a 
logging library has to be able to get you started with reading less than 3 
sentences about it (looking at it from both sides:  the person who puts the 
logger into some piece of source code as well as the person who's trying to 
retrieve messages of a specific level/domain -- that second part is 
specifically difficult with the current system IMO).  As I see it, part of the 
project should also involve writing a short but exhaustive documentation about 
how the logger should be used in the context of FreeType (just setting up a few 
basic guidelines to have everyone on the same page).

As for the logger itself it should be tried and tested across all thinkable 
(reasonable) platforms that FreeType supports (that should not be 
underestimated).  Also it should be supported by a community that can be 
trusted with developing it for a foreseeable future as we don't really want to 
replace the logger on a yearly basis ;)

That's all I can think about it for the moment ... if I come across something 
else I will add it to the thread.

@Werner:  I would be happy to help out as much as I can, I just don't know any 
details about my Summer yet.

Armin