[Vortex] side effect of restoring default log handler

[Philip Kovacs]

Philip Kovacs wrote:
>
> I'm using vortex svn, and rev 2071 has this patch, so I installed 
> that.   If VORTEX_DEBUG
> in unset, all is well, but if you set it, vortex handlers takes over 
> again.   It should be possible
> to restrict use of your handlers even when using VORTEX_DEBUG.
> Phil
>
> N.B. I think that all that debug code should be conditionally compiled,
>        i.e. configure --enable-debug and --disable-debug.
>

There is another, related and pervasive problem.  I use the following 
code fragment
in my debug builds in order to force an abort on warning and higher log 
levels: 
(This is an extremely common technique):

#ifdef G_ENABLE_DEBUG
   g_log_set_always_fatal (G_LOG_LEVEL_CRITICAL | G_LOG_LEVEL_WARNING);
#endif

I can't use this now to debug my code since vortex logs warning 
messages, even
with VORTEX_DEBUG unset.  In vortex_profiles.c, for example:

       profile = vortex_hash_lookup (registered_profiles, uri);
       if (profile == NULL) {
               g_log (LOG_DOMAIN, G_LOG_LEVEL_WARNING, "Attempting to 
configure mime and content type configura
tion over a profile not registered (%s)",
                      uri);
               return;
       }

All you see is an immediate abort with no message if VORTEX_DEBUG is unset.
So this raises the question of the purpose of these messages.  If they 
are intended
as internal debugging messages, you _must_ provide a means of building 
vortex
without them, or, minimally, lower the glib level of the messages to 
nothing higher
than 'info' or 'debug'.  If, however,  they are messages that you want 
clients of the
library to see in normal, production use, thats fine... but you must not 
require that
VORTEX_DEBUG be set in order to see them.

Regards,

Phil