RE: Let --disable-debug actually do something

[Medland, Bill]

> -----Original Message-----
> From: Alexandre Julliard [mailto:[e-mail]]
> Sent: Friday, December 06, 2002 12:53 PM
> To: Medland, Bill
> Cc: [e-mail]
> Subject: Re: Let --disable-debug actually do something
>
> "Medland, Bill"  writes:
> > --- wine/include/wine/debug.h	5 Jul 2002 21:22:09
>
> -0000	1.5
> > +++ wine/include/wine/debug.h	4 Dec 2002 04:52:22 -0000
> > @@ -23,6 +23,7 @@
> >
> > #include <stdarg.h>
> >  #include "windef.h"
> > +#include "config.h"
>
> You can't do that, installed includes shouldn't depend on config.h.

Oh.  So how is setting --disable-debug supposed to result in the FIXMES
being compiled out?  I just don't understand what is supposed to be
happening here; all I know is that it isn't working.  (Or is that not what
it is supposed to do?)

a) --disable-debug results in the settings in config.h changing.
b) wine/debug.h tests that setting that becomes defined in config.h, in
order to reduce FIXME to a basically null statement.
c) dlls/user/hook.c, for example, includes a FIXME statement.

neither hook.c nor debug.h include config.h so if I insert
    #ifndef NO_DEBUG_MSGS
    #error I was right
    #endif
just before the fixme of NotifyWinEvent
then it tells me I am right.

I can only think of two ways that setting --disable-debug could be expected
to result in the FIXMES being compiled out (which I presume is what is
supposed to happen).  Either it is supposed to result in a change to the
makefiles so the -D NO_DEBUG_MSGS gets specified (and I see no indication of
that) or else it results in a #define NO_DEBUG_MSGS at a suitable point that
comes before it is actually needed (which appears to be the intention).  So
I presume that the problem is that config.h is not being included before its
contents are needed.  So the question is where should it be included.  One
solution would be to include it explicitly in every file that includes a
WARN, FIXME or TRACE.  Do you really want that?  The other is to include it
in the file that uses it (viz. debug.h).

So tell me why I am an idiot and what solution you want me implement.  I
guess the simplest would be to drop --disable-debug from the configure.
> -- 
> Alexandre Julliard
> [e-mail]

Bill Medland

Let --disable-debug actually do something

[Alexandre Julliard]

"Medland, Bill"  writes:
> Oh.  So how is setting --disable-debug supposed to result in the FIXMES
> being compiled out?  I just don't understand what is supposed to be
> happening here; all I know is that it isn't working.  (Or is that not what
> it is supposed to do?)

It's what it's supposed to do, but it's clearly broken, and has been
for a very long time, basically because no one uses it.

A possible fix is to hack configure to pass the flags on the compiler
command-line; another is to remove the configure option completely and
just tell people who really want it to do something like:

make clean
   make all EXTRADEFS=-DNO_DEBUG_MSGS

Let --disable-debug actually do something

[Greg Turner]

On Friday 06 December 2002 03:27 pm, Alexandre Julliard wrote:
> "Medland, Bill"  writes:
> > Oh.  So how is setting --disable-debug supposed to result in the
> > FIXMES being compiled out?  I just don't understand what is
> > supposed to be happening here; all I know is that it isn't working.
> >  (Or is that not what it is supposed to do?)
>
> It's what it's supposed to do, but it's clearly broken, and has been
> for a very long time, basically because no one uses it.
>
> A possible fix is to hack configure to pass the flags on the compiler
> command-line; another is to remove the configure option completely
> and just tell people who really want it to do something like:
>
> make clean
>    make all EXTRADEFS=-DNO_DEBUG_MSGS

Unfortunately, I've seen packagers use it.  Gentoo, for example, uses 
it.  And I could see the logic: why would joe user want all these 
gibberish messages dumping onto the console while he's trying to work?

So, eliminating this from configure might be a good call IMHO, at least 
until we get it working.

Perhaps the wrapper scripts should control where the debugging output 
goes.  I.E.: we could support (1) the usual stuff (2) appending debug 
output to a log file or (3) appending debug output to /dev/null, 
without messing with DNO_DEBUG_MSGS....

just a thought,

Let --disable-debug actually do something

[Eric Pouech]

> > A possible fix is to hack configure to pass the flags on the compiler
> > command-line; another is to remove the configure option completely
> > and just tell people who really want it to do something like:
> >
> > make clean
> >    make all EXTRADEFS=-DNO_DEBUG_MSGS
>
> Unfortunately, I've seen packagers use it.  Gentoo, for example, uses
> it.  And I could see the logic: why would joe user want all these
> gibberish messages dumping onto the console while he's trying to work?
>
> So, eliminating this from configure might be a good call IMHO, at least
> until we get it working.
>
> Perhaps the wrapper scripts should control where the debugging output
> goes.  I.E.: we could support (1) the usual stuff (2) appending debug
> output to a log file or (3) appending debug output to /dev/null,
> without messing with DNO_DEBUG_MSGS....

at some point, I was also thinking of:
- implementing the wine debug messages with the
OpenEventLog/ReportEvent/EVENTLOGRECORD... API (using some specific wine
channels)
- implement those APIs with various log files capabilities (either
redirecting to stderr as we do now, or to some files in /var/log/wine/,
or /dev/null...)

but this would impact the performance of our logging, especially relay
logging :-(, no I never actually tried to do it

A+