Re: tracing and logging library - GSOC Project

[Priyesh kumar]

Hey,

Working forward in an external library hunt i came across two C based logging libraries:

1.log4c

2.zlog

In the above mentioned libraries zlog claims to be faster, more safer and powerful.

It is also well tested and mature, it also has a windows version.

Some of zlog's features which i think could be useful for this project are:

• log messages could be formatted according to our needs.
• It has six default log levels and we can also define our own log levels ( could be used to define 8 levels of debugging in FT_TRACE )
• Highly Accurate and 1000 times faster than syslog ( claimed in documentation )
• It is also self debuggable i.e. it can output it's own debug and error logs 
• Thread safe for multi process situations

I am also working on a prototype that will print log messages generated by FT_ERROR into a log file.

Please guide me if I am working in right direction..

On Thu, Feb 27, 2020 at 10:14 AM Priyesh kumar <address@hidden> wrote:

>In other words, my gut feeling says no to the idea of using any
>different code language. The logging facility should be written in
>the C language, too, not using more recent features than C99 so that
>older compilers support it.

Got it!! Thanks for your suggestion... I will keep this in mind.

>It's not a *requirement* to use an external logging library (in spite
>of the project's name), but there are good arguments to not re-invent
>the wheel. In particular, it can be expected that a well-maintained
>external library gets a lot of testing and comes with a mature API.

Thanks, I agree with your point that an external library would be well tested and mature. I thought in that direction as well but thought if somehow I could get rid of integrating an external library.

Since quality is an important aspect, I will focus on the external library part going forward.

As per my understanding FreeType's Logger consists of following basic Macros for printing log messages:
1.FT_ERROR: for serious error messages.
2.FT_ASSERT: for checking assertions at runtime.
3.FT_TRACE: for general-purpose debugging messages with 8 levels of debugging( 0 - 7 ). Different components in FreeType could have different debug level. These levels are specified using FT2_DEBUG environment variable.

Other logger features can be easily taken care( like they are today) if we find a replacement for above basic Macro functions.

Going forward, I will explore logging libraries and will check if one or more of them will meet the above requirements either by directly integrating them or by adding a little bit of logic on top of them.

Please guide me if I am on the right track.

Thank You

On Tue, Feb 25, 2020 at 12:00 PM Werner LEMBERG <address@hidden> wrote:

Hello Priyesh!


Thanks for your interest in FreeType.

>    [...] Therefore, I propose to implement separate code files for
>    logging, which could be based on C++ and can be easily plugged
>    into the existing C code base.  In addition to this, improving a
>    bit on documentation can contribute to better understating of
>    existing logger codebase.

I'm not sure I like this.

Debugging is at the very heart of FreeType.  Assume that you have to
identify a bug, and you work in an environment for an exotic platform
that only provides an (old) C compiler.  Your suggestion implies that
you no longer can activate debugging output at all on such a platform!

In other words, my gut feeling says no to the idea of using any
different code language.  The logging facility should be written in
the C language, too, not using more recent features than C99 so that
older compilers support it.

> Based on above points, all these changes could be done without
> embedding an external library.  Having said that, if it is really a
> requirement to replace the current logging facility with an external
> one, there is an external C based logging library named "Zlog"
> already been discussed on mailing list here
> <https://lists.nongnu.org/archive/html/freetype-devel/2019-01/msg00023.html>.
> I can work on it and explore other available external library
> option.

It's not a *requirement* to use an external logging library (inspite
of the project's name), but there are good arguments to not re-invent
the wheel.  In particular, it can be expected that a well-maintained
external library gets a lot of testing and comes with a mature API.


    Werner


PS: The current use of the debugging macros are documented in
    `doc/DEBUG`.