Log4g - A GObject-based logging utility
The initial intent of this project was to learn the GObject framework (and indirectly some Java) by porting Log4j classes directly to GObject classes. Perhaps some users of GLib and GObject will find this library useful.
Please report bugs on Github.
Setting up Log4g in your application requires three simple steps:
Include the main Log4g header file
Initialize the Log4g system
The initialization function should be called before you use the logging API. If you plan to use threads in your program you must initialize the GLib threading API before you initialize Log4g. If the threading system has not been initialized before calling log4g_init() then Log4g will not perform any locking or attempt to use any threading features.
Insert logging statements into your application
log4g_error("program failure: %s", error->message);
Log4g supports the notion of logging levels. There are 5 default logging levels in Log4g (custom logging levels are also supported). The default log levels are:
- TRACE via
- DEBUG via
- INFO via
- WARN via
- ERROR via
- FATAL via
If you would like to use a logger other than the root logger, you can
define the macro
LOG4G_LOG_DOMAIN before including the Log4g header file:
#define LOG4G_LOG_DOMAIN ("org.gnome.test") #include <log4g/log4g.h>
This sets the Log4g logging domain for the duration of that file. To use multiple logger instances from within the same file you will need to use a slightly different API:
log4g_logger_error(log4g_get_logger("org.gnome.foo"), "program failure: %s", error->message); log4g_logger_warn(log4g_get_logger("org.gnome.bar"), "you had better watch out %s", name);
These two log statements would use the "org.gnome.foo" & "org.gnome.bar" loggers respectively. Logger names use a class hierarchy in which classes are separated by the dot (".") character.
Cleanup the logger hierarchy
It is not strictly necessary to call finalize, however this will destroy the logger hierarchy. This may become important if you are using an asynchronous logger. Destroying the hierarchy will ensure that any pending asynchronous log messages are flushed before your application exits.
If you have used the default configuration (as in this example), log messages will be printed to stdout using the TTCC layout. For information on how to configure Log4g refer to the detailed documentation.
Log4g ships with an Autotools build environment. First run the provided configure script (supplying any desired options) and then run make:
$ tar zxf log4g-0.1.2.tar.gz $ cd log4g-0.1.2 $ ./configure $ make $ sudo make install
If you are building an unstable release (cloned with git) then you will have to generate the configure script by running autogen.sh. This requires that you have autoconf, automake and libtool installed. Refer to the Autotools documentation for more information.
Log4g is documented using GTK-Doc. To build the documentation pass the
--enable-gtk-doc flag to the configure script. The documentation will be
built when you type
Once the documentation is generated, point your web browser to:
A reasonably up to date version of the documentation can be found on Github.
Log4g is released under version 2.1 of the LGPL.