Re: tracing and logging library - GSOC Project

[Priyesh kumar]

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