Beman Dawes wrote:
On Wed, Jun 18, 2008 at 8:25 AM, troy d. straszheim <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I've seen this but haven't had time to dig in and solve it yet.
CPU usage drops to zero and the thing just sits there
Yes, those are the symptoms I'm seeing here.
(there is no
network connection open, that isn't the problem). There is
something fishy with the python subprocess stuff (on windows.
darwin/linux are fine.) that I haven't had time to look at.
Any Python win32api experts out there who could look at this?
I got this worked out, it took quite a number of tries. My vista box
is doing a good job now. I also threw together a little build slave
script, the builds posted on http://boost.resophonic.com/trac/traash
were done by boxes that are still periodically checking the cmake
release branch for new revisions. More when it is documented.
One thing that still happens is that "Visual C++ Debug Library Assertion
Failure" popups still come up, but the compile/link/test driver program
does time them out and kill them. GPFAULT dialogs don't appear at all.
There is a failing date_time test (testtime_wstream i believe) that
passes a null string to a function like sprintf() and the popup comes
from the guts of that function. Evan put me on to a way to suppress these:
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE );
_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDERR );
The test that causes this is just a program with a main() routine...
It seems like it should use boost.test, and boost.test should be
responsible for making these dialog-suppressing calls. (Does that sound
like it makes sense?)
-t
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
