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 _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel