|
|
Boost Interest : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-06-18 09:24:48
On Wed, Jun 18, 2008 at 8:25 AM, troy d. straszheim <troy_at_[hidden]>
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