Re: Logging Library-GSOC

[Priyesh kumar]

Hey,

This week I have explored several libraries and I have prepared a report mentioning their pros and cons @here

I am using Visual Studios 2019 to build libraries on windows, and while exploring the external libraries I have seen that most of the

libraries use <unistd.h> and <pthread.h> which are not supported on windows (even though it is mentioned in the documentation that 

the library supports Windows).

I have also tried Cygwin to compile these libraries on windows but got no success...

Is there a way to compile these libraries on windows other than using Visual Studios and Cygwin? More importantly, should I consider 

such libraries?

One more thing that I have noticed is that most of the libraries provide tags that could be printed with log messages.

So, I was thinking to use something like this in ftdebug.h to print the tracing component:

#define FT_COMPONENT( x ) FT_COMPONENT_TAG_( x )

#define FT_COMPONENT_TAG_ #x

#define FT_TRACE( level, varformat ) 

           do                                                                 \

           {                                                                  \

             if ( ft_trace_levels[FT_TRACE_COMP( FT_COMPONENT )] >= level ) { \

             set_tag( FT_COMPONENT_TAG( FT_COMPONENT ) );                     \

             FT_Log varformat;                                                \

           } while( 0 )                                                       \                                         

Please, look into the report and let me know if there are any concerns...

Thanks,

Priyesh

On Sun, May 24, 2020 at 3:22 PM <armin@hasitzka.com> wrote:

Hi Priyesh,

> 2. Modifying the output stream at runtime.
>
>    a. Dynamic change of desired output log levels.
>    b. Dynamic log redirection.
>
> [...]
>
> All of this should be configurable either with a config file or with
> environment variables.  I'm not sure how item 2 can be handled best; if this
> feature is active it maybe makes sense to force re-reading of environment
> variables and config files as sonn as a FreeType API function is called.

I believe a good way to handle point 2 (and blend in well with the rest of the project) is to allow overrides of the these values (from the config file or env variables) with dedicated functions at runtime; something like

```c
  FT_Trace_Set_Level( FT_Trace_Level  level );

  typedef void
  (*FT_Trace_Callback)( FT_Trace_Level  level,
                        const char*     fmt,
                        va_list         args );

  FT_Trace_Set_Callback( FT_Trace_Callback  callback );

  FT_Trace_Set_Default_Callback( void );
```

Note this is just a quick sketch and the actual callback function might have a forth parameter for the module ...  or this can be part of `fmt` and `args` ...  tbd :)

One thought also on the timestamps:  let's plan them flexible please (at least on/off toggle-able per env variable) as there's a good chance that you want to use your own TS format when retrieving the logs through the callback.

I totally agree with the rest :)

Have a lovely Sunday,
Armin