You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2007/11/02 05:53:33 UTC

Re: Intel C++ 9.1/Win XP build timeouts

Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] 
>> Sent: Saturday, October 27, 2007 12:58 AM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Intel C++ 9.1/Win XP build timeouts
>>
>> [Forwarding a private discussion]
>>
>> Farid, would it be possible to update the Windows build 
>> script(s) to write out the info below?
> 
>   Done: http://svn.apache.org/viewvc?rev=590279&view=rev

Great, thanks! Let's keep an eye on the Intel C++ builds on Windows
XP and try to figure out what the bottleneck is.

> 
>> Also, do you have any idea why the build cscript would refuse 
>> to die when killed like Andrew says?
> 
>   Because they are the different processes (cscript is the child
> process of the  build_xxx.bat). But when some process is killed
> the child processes are not killed. They would be killed if the all
> processes belongs to the same job object. But I don't know
> how create the job object and assign to it from the batch file.
> 
>   Maybe the BATMAN could do this before executing the batch file?

Sounds like that would be the right place to make the change. Let
me see if we can get it implemented on the Batman side of things,
or in the build script.

Travis, do you have enough experience with the Windows Scripting
Host to modify the stdcxx build script that Batman invokes to do
this?

Martin

Re: Intel C++ 9.1/Win XP build timeouts

Posted by Martin Sebor <se...@roguewave.com>.
Andrew Black wrote:
> Travis Vitek wrote:
>> Martin Sebor wrote:
>>> Farid Zaripov wrote:
>>>>   Maybe the BATMAN could do this before executing the batch file?
>>> Sounds like that would be the right place to make the change. Let
>>> me see if we can get it implemented on the Batman side of things,
>>> or in the build script.
>>>
>>> Travis, do you have enough experience with the Windows Scripting
>>> Host to modify the stdcxx build script that Batman invokes to do
>>> this?
>>>
>>> Martin
>>>
>> No, I don't have mush experience with WSH. I don't even know the name of the
>> script that Batman invokes for building stdcxx. I'm sure I could figure it
>> out though.
> 
> Batman invokes an internal glue script.  That script in turn 'call's the
> generated build_<compiler>.bat script.  My understanding of the
> semantics of the call batch command is that it executes the script in
> question within the current process (like the unix . operator).

Hmm. This really does seem like a Batman problem, Travis' comments
below notwithstanding. We shouldn't need to do anything special to
help Batman kill our own builds. Another way to look at it is that
Batman (or any test harness) shouldn't be relying on the products
it tests to function correctly.

> 
> --Andrew Black
> 
>> Unfortunately I'd prefer if we could find a solution outside of Batman.
>> Occasionally, I want to stop a build that I'm running locally. CTRL+C will
>> get my command prompt back, but it often leaves some of the other processes
>> running, or stuck in a bad state [devenv.exe, cscript.exe, exec.exe, ...].

I've noticed this too. It is annoying and it would be nice to fix
it (even if Batman does implement its own solution). Unfortunately,
I know next to nothing about WSH or Windows job control and I doubt
I'll have the time or the energy to work on it in the near future.
If someone would like to look into it as their pet project that
would be cool ;-)

Martin

Re: Intel C++ 9.1/Win XP build timeouts

Posted by Andrew Black <ab...@roguewave.com>.
Travis Vitek wrote:
> Martin Sebor wrote:
>> Farid Zaripov wrote:
>>>   Maybe the BATMAN could do this before executing the batch file?
>> Sounds like that would be the right place to make the change. Let
>> me see if we can get it implemented on the Batman side of things,
>> or in the build script.
>>
>> Travis, do you have enough experience with the Windows Scripting
>> Host to modify the stdcxx build script that Batman invokes to do
>> this?
>>
>> Martin
>>
> 
> No, I don't have mush experience with WSH. I don't even know the name of the
> script that Batman invokes for building stdcxx. I'm sure I could figure it
> out though.

Batman invokes an internal glue script.  That script in turn 'call's the
generated build_<compiler>.bat script.  My understanding of the
semantics of the call batch command is that it executes the script in
question within the current process (like the unix . operator).

--Andrew Black

> 
> Unfortunately I'd prefer if we could find a solution outside of Batman.
> Occasionally, I want to stop a build that I'm running locally. CTRL+C will
> get my command prompt back, but it often leaves some of the other processes
> running, or stuck in a bad state [devenv.exe, cscript.exe, exec.exe, ...].
> 
> Travis

Re: Intel C++ 9.1/Win XP build timeouts

Posted by Travis Vitek <vi...@roguewave.com>.


Martin Sebor wrote:
> 
> Farid Zaripov wrote:
>> 
>>   Maybe the BATMAN could do this before executing the batch file?
> 
> Sounds like that would be the right place to make the change. Let
> me see if we can get it implemented on the Batman side of things,
> or in the build script.
> 
> Travis, do you have enough experience with the Windows Scripting
> Host to modify the stdcxx build script that Batman invokes to do
> this?
> 
> Martin
> 

No, I don't have mush experience with WSH. I don't even know the name of the
script that Batman invokes for building stdcxx. I'm sure I could figure it
out though.

Unfortunately I'd prefer if we could find a solution outside of Batman.
Occasionally, I want to stop a build that I'm running locally. CTRL+C will
get my command prompt back, but it often leaves some of the other processes
running, or stuck in a bad state [devenv.exe, cscript.exe, exec.exe, ...].

Travis
-- 
View this message in context: http://www.nabble.com/Intel-C%2B%2B-9.1-Win-XP-build-timeouts-tf4699975.html#a13552059
Sent from the stdcxx-dev mailing list archive at Nabble.com.