Re: [ft-devel] Logging library proposal

[Werner LEMBERG]

>> I want to work on your project titled "Replace FreeType's tracing
>> and debugging facilities with an external logging library".  You
>> have mentioned that there are platforms where stderr is not
>> accessible.  Can you give me an example of such a platform?

Windows in GUI mode.

>> 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.

>> There is a library "zlog" - https://github.com/HardySimpson/zlog
>> supporting logging into a file.  It is similar to log4j and
>> log4cpp. It has pretty good features.  Its documentation is good,
>> it is well maintained and is licensed under LGPL-v2.1.  A windows
>> version is also available for it.  According to me, zlog will serve
>> the purpose.

This is something to be evaluated as part of the GSoC project.

>> 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.

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?

> Please don't use an external library.  Logging in FreeType is for
> developers only, and some parts maybe for font designers.  Clients
> who just want to render text don't need the logging capabilities.
> Just keep it simple.

Of course.  Only if some preprocessor macros are defined at configure
time, this feature is available – I won't change that.  In other
words, it will stay as a developer-only feature.  Irrespective of
that, good debugging messages are *invaluable* and thus worth to be
improved.


    Werner