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.

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

(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.