Prior to this change, there were spurious build failures seen in Github
CI, especially on macOS builds, where one test out of ~2000 would fail
randomly. After adding an option to display the diagnostics, it was
determined that the failure was only in the tests that included the
timestamp. This was because the time call was returning different values
between `test_setup` and `pinelog_log_message`. Even though they may
have been called milliseconds apart, the time skew was enough to have a
1 second difference between the two returned values.
This change overrides the `time` method from libc, and returns a static
value. With this change, CI should work fine regardless of how slow the
tests run.
This commit adds the following changes to pinelog:
- Optional buffer to write the message to prior to writing to the output
stream. This reduces the likelihood of log messages from multiple
threads interleaving due to multiple calls to fputs/fprintf, etc. The
default is to still write directly to the output stream, but the
integrator can add a define of PINELOG_BUFFER_SZ to the CFLAGS, and
this will allow the application to log messages that are shorter than
the above size, including the timestamp, level and backtrace if any.
- Optional module level logging. This allows more fine-grained
debugging, where the application can control the log levels of the
individual modules. By default, when modules are configured, they
default to the global log level, but this can be overridden by the
application.
Prior to this change, the test harness was creating a FIFO on disk using
`mkfifo`. This is really unnecessary, and we can use `pipe` instead to
create a pair of file descriptors corresponding to a FIFO in memory,
without having to go to disk at all.
This change creates the FIFO and sets it to non-blocking to emulate the
existing behavior.
Prior to this change, pinelog used __FILE__ in the backtrace call.
However, this has a limitation that if used in a build system with
sources in subdirectories and/or a separate build directory, the
relative path to the file is used, giving us a backtrace like this.
../../daemon/x52d_main.c:51
This change checks if the compiler supports the __builtin_strrchr to
compute the file basename at compile time. If the compiler does not
support it, it falls back to using __FILE__ directly. This should not be
an issue on a modern compiler like gcc or clang.
nirenjan