Re: [Boost-cmake] Test feedback
On Sun, Jun 29, 2008 at 9:41 AM, troy d. straszheim [EMAIL PROTECTED] wrote: David Abrahams wrote: troy d. straszheim wrote: 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?) 1. I'm reluctant to recommend that any program use Boost.Test until its documentation is made to correspond to its actual interface. 2. You'd better ask Gennadiy what makes sense for Boost.Test; I don't understand the rationale by which it gets developed 3. Maybe we could have an option in boost/detail/lightweight_test, or simply a separate header called boost/detail/regression.hpp that includes something that does this. Maybe the old dynamically-initialized static member of a template trick makes sense here. Roger that, skipping to #3... Before inventing something new, why not ask the Boost.Build folks how they suppress unwanted pop ups during Boost regression tests. They went through the exact same sequence you are now repeating; first a lot of popups occurred, then a few, then a few that closed automatically after some time, and finally none at all. That's regardless of whether the test involved is running under Boost.Test or not. Also, are you aware Boost.Test already has the equivalent of lightweight_test? See trunk\boost\test\minimal.hpp. If minimal.hpp is missing something, shouldn't the missing feature be added there rather inventing a whole new kind of lightweight test? --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Test feedback
Beman Dawes wrote: I went back and set BOOST_BUILD_SLAVE_HOSTNAME to vista.dc.resophonic.com http://vista.dc.resophonic.com/, then tried nmake /I test. It runs for a bit and then pauses for a long time, then runs a bit more, etc. At this rate it will take days to run the full set of tests. Is that normal? 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? It looks like you can fix this pretty easily by using subprocess.communicate() instead of subprocess.wait(), but then you get other problems with Visual Studio Debug Library Assertion Failure Popups, how to monitor/timeout the subprocesses, etc. I created a ticket on this one as well: http://svn.boost.org/trac/boost/ticket/2043 -t ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Test feedback
On Wed, Jun 18, 2008 at 8:25 AM, troy d. straszheim [EMAIL PROTECTED] wrote: Beman Dawes wrote: I didn't have a clue as to what BOOST_BUILD_SLAVE_HOSTNAME should be, so just left it blank. That resulted in the Traash Demo Hostname being set to bgd.myhome.westell.com http://bgd.myhome.westell.com, which I doubt is meaningful. meaningful enough What should it be set to and how would I know that? If it is always to be set to vista.dc.resophonic.com http://vista.dc.resophonic.com, why do I have to set it? I tried to tune up the docs on this one: BOOST_BUILD_SLAVE_HOSTNAME This will change the hostname reported to the server, if you'd like to keep your internal hostnames completely private or make them more descriptive. This hostname should be unique among build slaves, and something generally descriptive and not too long would be nice, as this name is used fairly frequently in build result displays. Much better! We might want to come up with naming conventions. Say I'm running two Linux slaves, and two Windows slaves. Would names like this be a good idea? bgd.vista.vc++.9.0 bgd.vista.vc++.8.0 bgd.linux.gcc.4.3.c++03 bgd.linux.gcc.4.3.c++0x So it isn't just the DNS hostname of the slave, it is more an identifier for the slave that defaults to DNS hostname. This is because on pages like this: http://boost.resophonic.com/trac/traash it would be nice to be able to see that e.g. Beman's build box has 17 more errors than Troy's... so we don't want all the vistas to have their hostnames set to vista.dc.resophonic.com. I went back and set BOOST_BUILD_SLAVE_HOSTNAME to vista.dc.resophonic.com http://vista.dc.resophonic.com/, then tried nmake /I test. It runs for a bit and then pauses for a long time, then runs a bit more, etc. At this rate it will take days to run the full set of tests. Is that normal? 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? --Beman ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
