stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [PING] Re: library and build sizes on Windows
Date Mon, 10 Dec 2007 22:09:36 GMT
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Monday, December 10, 2007 9:30 AM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: RE: [PING] Re: library and build sizes on Windows
>>
>>
>> I've been doing some work on the test result scripts over the 
>> weekend and noticed a whole bunch of places where we print 
>> out the date on Windows (I counted 12). I dealt with it by 
>> trimming all but the first one from the log when processing 
>> it but we should probably get rid of all the extra dates and 
>> either replace them with the same output as on UNIX if 
>> possible (i.e., real, user, ans system times) or just the 
>> real time. Can this be done on Windows?
> 
>   I've added printing the real time of the every build step:
> http://svn.apache.org/viewvc?rev=602995&view=rev
> 
>   But batman script also should to be updated to print the timestamp
> of the build at the beginning ("### date:"); the duration of the
> solution generating step ("### real time (builddir):") after execution
> of the configure.bat and total time at the end after cleanup
> ("### real time (total):"). All these actions are performed outside
> the build.wsf script.

Alright. We need to migrate this script from Batman over to stdcxx
so we can enhance it ourselves. In addition to the timing info and
the library size I also tried (but couldn't) to determine the name
and version of the Windows OS so even the latest test result pages
for Windows are incomplete.

Andrew, I'm having trouble finding this script. Can you point me
in the right direction?

> 
>   As for the kernel and user time spent to the each step: it's hard to
> implement because we need to summarize the all times of the each
> subprocess. The GetProcessTimes() returns the times only for concrete
> process and not returning the times of the children processes, like does
> times() on unix.

Hm. We might need to settle for the real times on Windows.

Martin


Mime
View raw message