libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactiv


From: Peter Rosin
Subject: Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.
Date: Wed, 20 Oct 2010 18:53:34 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5

Den 2010-10-20 17:55 skrev Charles Wilson:
> On 10/20/2010 2:31 AM, Peter Rosin wrote:
>> Den 2010-10-05 13:33 skrev Peter Rosin:
>>> I have implemented exactly that and just posted this to the MinGW patch
>>> tracker:
>>> http://sourceforge.net/tracker/index.php?func=detail&aid=3081421&group_id=2435&atid=302435
>>
>> The silence is deafening. 
>>
>> Chuck, have you looked at this?
> 
> Yes, I have -- but MSYS patches are Cesar's domain.  I guess I could
> ping him...
> 
> wait...
> 
> Looks like Cesar responded earlier today.  Coincidence?

Yes, I think that was a coincidence.

> I understand wanting to keep the current (popup-showing) behavior for
> most MSYS process trees, since many users may rely on that information
> to indicate real problems.

Yes, that was high priority.

> I wish there was some way to activate your patch other than launching
> the top-level shell/window thru a run.exe-like starter app...but since
> it has to be done before any other msys apps in the process tree start,
> that means it probably should be done inside msys.bat itself (via an
> --option?) somehow.

The other ways to activate that I can think of is via some environment
variable, but checking that for every new process is going to add on
to the already painful fork cost. Either that or using some interface
like cygwin_internal to manipulate "myself->children_error_mode", but
that would require adding a shopt to bash that sets the desired error
mode and that it should be inherited by future children. And what about
other shells?

> However, msys.bat launches its target (either rxvt or bash) via the
> win32 program start.exe.  So, we could launch the target using EITHER
> start.exe OR your wrapper, depending on --no-popups.  But then the
> wrapper would need to be a lot smarter (e.g. use CreateProcess instead
> of execve, so that it can set the CONSOLE hiding flags...but then, THAT
> would use a different startup path inside msys.dll, and your patch
> wouldn't activate!)
> 
> So, I don't think there is a "better" way than
> 
>    error_mode.exe -cgf C:/mingw/msys/1.0/msys.bat [--rxvt]
> 
> if we (MSYS) want to preserve existing popup-showing behavior at all --
> which I think we do.  MAYBE the following (pseudo-bat-code, where
> MSYS_NOPOP is set based on --no-popups arg to .bat file):
> 
>    if "x%MSYS_NOPOP%" == "x" goto startrp
>    start %WD%error_mode -cgf /bin/rxvt {other args}
>    exit
> 
>    :startrp
>    start %WD%rxvt {other args}
>    exit
> 
> with similar changes for the --no-rxvt case. It's sorta clunky, but it
> might work.

Yes, integration in msys.bat would be nice.  But this is a corner case,
and if you create a shortcut (which I have done), it really doesn't
matter how you spell it.  But as I said, it still would be nice.

> But...that's something for the msys-dvlpr list to hash out.
> Technically, I think your patch is fine.

I assume you mean the closed mingw-dvlpr list? In that case, I can't
join the fun, since I'm not a member...

(This is getting off topic)

Cheers,
Peter



reply via email to

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