Re: [Boost-cmake] Test feedback

[David Abrahams]

Beman Dawes wrote:

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

Excellent point, but I assumed that Troy had already investigated that
code since the suggestion has already been made in this thread.  I have
the impression that because of the way CMake launches build commands,
the BB technique doesn't work all by itself(?)

> Also, are you aware Boost.Test already has the equivalent of
> "lightweight_test"? See trunk\boost\test\minimal.hpp.  

Is that really equivalent?  IIUC, at the very least, minimal.hpp still
defines your main() for you.

> If minimal.hpp is
> missing something, shouldn't the missing feature be added there rather
> inventing a whole new kind of lightweight test?

I wasn't proposing an additional kind of test; I was proposing a
facility one could #include in a TU that would suppress error dialogs on
Windows.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
___
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]

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

[troy d. straszheim]

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

-t
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

Re: [Boost-cmake] Test feedback

[David Abrahams]

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.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

Re: [Boost-cmake] Test feedback

[troy d. straszheim]

Beman Dawes wrote:
On Wed, Jun 18, 2008 at 8:25 AM, troy d. straszheim <[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

Re: [Boost-cmake] Test feedback

[troy d. straszheim]

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

[Beman Dawes]

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

Re: [Boost-cmake] Test feedback

[troy d. straszheim]

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
, 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 , 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 , 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@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake


___
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]

On Tue, Jun 17, 2008 at 3:37 PM, Beman Dawes <[EMAIL PROTECTED]> wrote:

>
>
> On Tue, Jun 17, 2008 at 10:43 AM, troy d. straszheim <[EMAIL PROTECTED]>
> wrote:
>
>> Beman Dawes wrote:
>>
>>> I'm still hung at the step that says " Enable BOOST_BUILD_SLAVE and
>>> BOOST_BUILD_TESTING."
>>>
>>> There are no such entries to enable.
>>>
>> >
>>
>> Does this help?
>>
>>  http://svn.boost.org/trac/boost/wiki/CMakeWindowsRegressionQuickstart
>
>
> Much better!
>
> 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, which I doubt is meaningful. What should it be set
> to and how would I know that? If it is always to be set to
> vista.dc.resophonic.com, why do I have to set it?
>

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

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

On Tue, Jun 17, 2008 at 10:43 AM, troy d. straszheim <[EMAIL PROTECTED]>
wrote:

> Beman Dawes wrote:
>
>> I'm still hung at the step that says " Enable BOOST_BUILD_SLAVE and
>> BOOST_BUILD_TESTING."
>>
>> There are no such entries to enable.
>>
> >
>
> Does this help?
>
>  http://svn.boost.org/trac/boost/wiki/CMakeWindowsRegressionQuickstart


Much better!

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, which I doubt is meaningful. What should it be set
to and how would I know that? If it is always to be set to
vista.dc.resophonic.com, why do I have to set it?

Thanks,

--Beman

--Beman
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

Re: [Boost-cmake] Test feedback

[KSpam]

Beman,

On Tuesday 17 June 2008 05:04:05 Beman Dawes wrote:
> I'm still hung at the step that says " Enable BOOST_BUILD_SLAVE and
> BOOST_BUILD_TESTING."
>
> There are no such entries to enable.

You might have to show "advanced" configuration options.  You should see a 
checkbox on the GUI for this.

Hope This Helps,
Justin
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

Re: [Boost-cmake] Test feedback

[troy d. straszheim]

Justins's suggestion:

It seems like it would be easier to have a testing 
configuration file that specifies the necessary configuration options.  For 
example, we could have "BoostTestingSlave.cmake"


was a good one, you can hide details and reduce the number of steps and 
avoid editing the cache.


Please see

  http://svn.boost.org/trac/boost/wiki/CMakeForRegressionTesters

for updates to the procedure.

-t
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

Re: [Boost-cmake] Test feedback

[troy d. straszheim]

KSpam wrote:
I can see how these CMake specifics can be very confusing to someone that is 
not used to CMake.  It seems like it would be easier to have a testing 
configuration file that specifies the necessary configuration options.  For 
example, we could have "BoostTestingSlave.cmake" with the following contents:


#---
# BoostTestingSlave.cmake
#---

set(BOOST_BUILD_SLAVE ON CACHE BOOL "Documentation ..." FORCE)
set(BOOST_BUILD_TESTING ON CACHE BOOL "Documentation ..." FORCE)

With a config file, the user would not be required to manually edit cache 
variables (and reconfigure, etc).  The process would look something like 
this:


1) Checkout sources:
svn co https://somerepo somerepo
2) Create build directory:
mkdir build
3) Configure build directory:
cd build
cmake -C BoostTestingSlave.cmake ../somerepo
4) Everything is ready to build!
make


Yeah, that could be a good way to go.  The two-step configuration is a hassle.
Let me give it a shot.

-t

___
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]

On Mon, Jun 16, 2008 at 5:38 PM, KSpam <[EMAIL PROTECTED]> wrote:

> On Monday 16 June 2008 12:58:23 Beman Dawes wrote:
> > * The "Configuration testing" section is totally opaque to someone (me!)
> > who has never used edit_cache. Any why is it called "edit_cache"? It
> > appears to be configuration settings that are being edited.
> >
> > Specifically, say that running nmake edit_cache will run a graphical
> > configuration editor. Maybe show a screen shot.
> >
> > "enable BOOST_BUILD_SLAVE and BOOST_BUILD_TESTING." How? What buttons do
> > you click? Are these already present? If not, how do you add an entry? If
> > so, where are they? All the names I can see begin "BUILD_BOOST_", not
> > "BOOST_BUILD_".
> >
> > " Reconfigure." How? Please be pedantic; say "Reconfigure by clicking the
> > 'Configure' button"
>
> I can see how these CMake specifics can be very confusing to someone that
> is
> not used to CMake.  It seems like it would be easier to have a testing
> configuration file that specifies the necessary configuration options.  For
> example, we could have "BoostTestingSlave.cmake" with the following
> contents:
>
>#---
># BoostTestingSlave.cmake
>#---
>
>set(BOOST_BUILD_SLAVE ON CACHE BOOL "Documentation ..." FORCE)
>set(BOOST_BUILD_TESTING ON CACHE BOOL "Documentation ..." FORCE)
>
> With a config file, the user would not be required to manually edit cache
> variables (and reconfigure, etc).  The process would look something like
> this:
>
> 1) Checkout sources:
>svn co https://somerepo somerepo
> 2) Create build directory:
>mkdir build
> 3) Configure build directory:
>cd build
>cmake -C BoostTestingSlave.cmake ../somerepo
> 4) Everything is ready to build!
>make


The goal has got to be set higher than even that! All of this needs to be
wrapped inside a script or preferably an installer.

Remember, sometimes the slaves will be run by IT folks who know nothing
about any of this. Sometimes testing will be run by developers or users who
have never even heard of make or nmake. Also, the wrapper/installer needs to
adapt to those who want to test multiple compilers.

Those who subscribe to this list are presumably willing to put up with more
complex configuration, but that's just short term. Long before this stuff
goes live, it needs to be packaged attractively, as Troy and Doug are
planning.

--Beman
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

Re: [Boost-cmake] Test feedback

[troy d. straszheim]

Beman Dawes wrote:

I'm still hung at the step that says " Enable BOOST_BUILD_SLAVE and
BOOST_BUILD_TESTING."

There are no such entries to enable.

>

Does this help?

  http://svn.boost.org/trac/boost/wiki/CMakeWindowsRegressionQuickstart

it's BUILD_TESTING, not BOOST_BUILD_TESTING, my fault.  But BOOST_BUILD_SLAVE 
should
be there, created by this line:

  option(BOOST_BUILD_SLAVE "Be a build slave, report build/testing" OFF)

of this file:

  
http://svn.boost.org/trac/boost/browser/branches/CMake/release/tools/build/CMake/BoostBuildSlave.cmake

-t
___
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]

On Mon, Jun 16, 2008 at 7:14 PM, troy d. straszheim <[EMAIL PROTECTED]>
wrote:

> Beman Dawes wrote:
>
>> Troy,
>>
>> Here is some initial feedback"
>>
>
> Hey Beman,
>
> All good feedback.  I neglected to mention that the documents assume
> that the reader is familiar with building/configuring via cmake. They've
> been updated, but could still use some work... and we now have a
> wiki page about testing with cmake that is completely out of date.
> I'll make another pass at these docs and let you know.


I'm still hung at the step that says " Enable BOOST_BUILD_SLAVE and
BOOST_BUILD_TESTING."

There are no such entries to enable.

--Beman
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

Re: [Boost-cmake] Test feedback

[KSpam]

On Monday 16 June 2008 12:58:23 Beman Dawes wrote:
> * The "Configuration testing" section is totally opaque to someone (me!)
> who has never used edit_cache. Any why is it called "edit_cache"? It
> appears to be configuration settings that are being edited.
>
> Specifically, say that running nmake edit_cache will run a graphical
> configuration editor. Maybe show a screen shot.
>
> "enable BOOST_BUILD_SLAVE and BOOST_BUILD_TESTING." How? What buttons do
> you click? Are these already present? If not, how do you add an entry? If
> so, where are they? All the names I can see begin "BUILD_BOOST_", not
> "BOOST_BUILD_".
>
> " Reconfigure." How? Please be pedantic; say "Reconfigure by clicking the
> 'Configure' button"

I can see how these CMake specifics can be very confusing to someone that is 
not used to CMake.  It seems like it would be easier to have a testing 
configuration file that specifies the necessary configuration options.  For 
example, we could have "BoostTestingSlave.cmake" with the following contents:

#---
# BoostTestingSlave.cmake
#---

set(BOOST_BUILD_SLAVE ON CACHE BOOL "Documentation ..." FORCE)
set(BOOST_BUILD_TESTING ON CACHE BOOL "Documentation ..." FORCE)

With a config file, the user would not be required to manually edit cache 
variables (and reconfigure, etc).  The process would look something like 
this:

1) Checkout sources:
svn co https://somerepo somerepo
2) Create build directory:
mkdir build
3) Configure build directory:
cd build
cmake -C BoostTestingSlave.cmake ../somerepo
4) Everything is ready to build!
make

By the way, I am very excited about building Boost with CMake!

Hope This Helps,
Justin
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

Re: [Boost-cmake] Test feedback

[troy d. straszheim]

Beman Dawes wrote:

Troy,

Here is some initial feedback"


Hey Beman,

All good feedback.  I neglected to mention that the documents assume
that the reader is familiar with building/configuring via cmake. 
They've been updated, but could still use some work... and we now have a

wiki page about testing with cmake that is completely out of date.
I'll make another pass at these docs and let you know.

By the way it would be awfully nice to get the xmlrpc plugin installed 
on svn.boost.org...  you can edit your wiki pages right in emacs.


Thanks,

-t
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

[Boost-cmake] Test feedback

[Beman Dawes]

Troy,

Here is some initial feedback"

* > make a working directory somewhere, check out the source to "src" and
make a directory "build". CD into "build" and execute

This is less than clear. What source? Check out from where? Do the
directories actually have to be named "src" and "build"? If so, why does
your example use other names? Also, your cmake invocation uses the name
"..\Source Directory", but isn't that supposed to be the same as "src"?

It would be clearer if you actually showed all the commands, including the
svn command, that need to be given, and then spelled out which directory
names were required and which could be chosen by the tester.

* The "Configuration testing" section is totally opaque to someone (me!) who
has never used edit_cache. Any why is it called "edit_cache"? It appears to
be configuration settings that are being edited.

Specifically, say that running nmake edit_cache will run a graphical
configuration editor. Maybe show a screen shot.

"enable BOOST_BUILD_SLAVE and BOOST_BUILD_TESTING." How? What buttons do you
click? Are these already present? If not, how do you add an entry? If so,
where are they? All the names I can see begin "BUILD_BOOST_", not
"BOOST_BUILD_".

" Reconfigure." How? Please be pedantic; say "Reconfigure by clicking the
'Configure' button"

That's all for now; I'll try again later.

--Beman
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake