-----Original Message----- From: Alexandre Julliard [mailto:julliard(a)winehq.com] Sent: Friday, December 06, 2002 12:53 PM To: Medland, Bill Cc: wine-devel(a)winehq.com Subject: Re: Let --disable-debug actually do something
"Medland, Bill" <Bill.Medland(a)accpac.com> 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 julliard(a)winehq.com
Bill Medland
"Medland, Bill" <Bill.Medland(a)accpac.com> 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 -- Alexandre Julliard julliard(a)winehq.com
On Friday 06 December 2002 03:27 pm, Alexandre Julliard wrote:
"Medland, Bill" <Bill.Medland(a)accpac.com> 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, -- gmt
> > 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+
participants (4)
-
Alexandre Julliard -
Eric Pouech -
Greg Turner -
Medland, Bill