I am thinking in preparing a simple logging function to be used mostly
for development and debugging purposes. It would allow to enable at
configure level not only the level of debug wanted, but also which
modules should have the logging enabled.
Don't spend too much time on a logging function; it has been done so
many times in the past. For most purposes, printing debug information
to stderr is good enough. The only exceptions I can think of to using
just plain stderr are:
1. you write a daemon, in which case messages (only very important
ones) should go to the system logger.
2. you have a multithreaded program and have concurrency issues;
in such a case a logger with a high-res timestamp and locking can be
useful.
After 20 years of programming, I can say that log files in general really
are not very useful for debugging. If you think a lot about something
before writing a message, you will find you have very few actually
useful messages. What would be far more useful than debug messages
are test scripts using whatever scripting language you like and your
favorite debugger (gdb). Input for testing various things (overflows, etc)
is also useful - this usually requires quite a bit of skill since the test input
is often generated by hand or with a small purpose-built program.
Just as a small example of why logs are not really useful - let's say the
program hangs. Some people would say "Oh, I'll make a function
tracer". Well, you may have a few hundred MB to go through in your
function tracer's log as opposed to maybe only 4MB for a core file; in
addition to that, who knows if you will actually log the call which hung.
When the program appears to hang, the best thing to do is attach a
debugger and then you see the last few function calls and can actually
inspect variables.