[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] NDEBUG

From: Vadim Zeitlin
Subject: Re: [lmi] NDEBUG
Date: Mon, 27 Oct 2014 19:32:41 +0100

On Sun, 26 Oct 2014 18:50:53 +0000 Greg Chicares <address@hidden> wrote:

GC> >  So from my point of view it would be ideal to use stderr only if it's
GC> > available. Normally this would be done using
GC> > 
GC> >   wxTheApp->GetValidTraits().CanUseStderr()
GC> > 
GC> > under wxMSW (perhaps surprisingly, checking for this is quite non 
GC> (And I won't suggest making it worse by trying to detect MinTTY.)

 I had actually already thought about it and we could, in principle, just
check for TERM and interpret "xterm*" as indicating MinTTY. But then we'd
also need to check for "screen". And there are probably more complications
that I didn't think about immediately. So I don't think we want to go

GC> > Hence it doesn't seem like we're going to be [easily]
GC> > able to detect it automatically.
GC> Then let's look for a different way to handle the MSVC case.

 Just for the record, because I'm not sure if I had expressed this
sufficiently clearly, what I meant by "not being able to detect it
automatically" was to not even try to do it and control this behaviour
manually instead, e.g. just add some --log-stderr option.

GC> How about this, using the LMI_MSC macro from 'config.hpp'?
GC> + #if defined LMI_MSC
GC>   wxLog::SetActiveTarget(new wxLogStderr);
GC> + #endif // defined LMI_MSC
GC> But I guess the condition you want is not whether it was compiled
GC> with ms tools, but whether it's running under the ms debugger

 Exactly. The above change would mean that things don't regress for me, but
it would be actually nice to get debug output, if any, on the console when
testing even MSVC-compiled binaries from MinTTY.

GC> are there any good ideas in this link?
GC> I haven't checked whether MinGW's headers offer IsDebuggerPresent(),
GC> but I guess we can just write its prototype inline;

 We can use wxIsDebuggerRunning(), which is just a wrapper for
IsDebuggerPresent(), but doesn't require including <windows.h> directly.

 To summarize, I think setting wxLogStderr as active log target only if
wxIsDebuggerRunning() returns false is indeed the best solution. Thanks for
thinking about it!

GC> though I don't know whether that would create a problem for you with
GC> gdb.

 No, I don't think so.

GC> How about testing whether the...
GC> | module name of the current process contains the string ".vshost"
GC> ?

 Just for the reference, VS host process is used for .NET programs only to
the best of my knowledge (and is optional for them).

 Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]