On Fri, 7 Nov 2003, Robert Crosbie wrote:

After selecting Inkscape->About Inkscape and seeing 421 "ensure outline - outlines" and "finalize - outlines" fly by on the console, It got me thinking about debugging messages.

It seems that many modules in inkscape turn on or off debugging by #defining a variable. It might be nice to be able to set a global debugging variable and/or debugging level through some method such as a command line option or an environment variable.

You could call 'Inkscape --debug 3' or 'setenv INKSCAPE_DEBUG 1'

As a developer it saves the time needed to undefine a variable and recompile, just to get debugging output.

These are some really good points. It's not typical for GUI apps to be printing to stderr and stdout unless something is not right - and even then its more usual to display an error dialog.

I've seen other applications with debugging levels such as 1 = LOW to 5 = HIGH, or from less detailed to very detailed.

I like the --debug=N approach and have used it myself quite a bit. But I think this codebase would require something a bit more aggressive. How about this idea:

inkscape --debug_all=1 \ --debug_foo=3 \ --debug_bar=5 \ --debug_baz=0

where foo, bar, and baz correspond to 'subsystems' in the codebase that one would like to get debug info for, and "debug_all" represents all modules. The number gives a relative setting; 1 would print entry into the functions (so --debug_all=1 is effectively turning on a running trace stream); 5 would display all messages for the given module.

Now, there's at least two arguments against this. One argument is that much of this info can be obtained via gdb. That's true, however sometimes being able to just get a stream of debug messages is the fastest way to narrow in on the problem; also, many people don't know gdb - this system is simple enough that end users could use it to help get info for their bug reports. A second argument is that it would be difficult at this point to add debug messages into the codebase since there's so much code; that's also true, but this approach would let us build it in subsystem-by-subsystem, as needed, and it's simple enough work that it can be distributed pretty evenly amongst us, as it'd require only pretty basic C coding capabilities.

Another option is to have a './configure --DEBUG' to turn on or off debugging. This way you can still ifdef the debugging messages and have them displayed during development, but you can stop them from even being compiled for a release version.

I think this is also a good idea. Being able to entirely strip out the debug logic allows us to maximize the performance of the production version of the code, but be very verbose in our debug messaging.

Bryce