Boost logo

Boost Interest :

From: troy d. straszheim (troy_at_[hidden])
Date: 2008-06-18 08:25:49

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
> <>, 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 <>, why
> do I have to set it?

I tried to tune up the docs on this one:


> 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:

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

> I went back and set BOOST_BUILD_SLAVE_HOSTNAME to
> <>, 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.

> ------------------------------------------------------------------------
> _______________________________________________
> Boost-cmake mailing list
> Boost-cmake_at_[hidden]

Boost-cmake list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at