On Mon, Jun 16, 2008 at 5:38 PM, KSpam <keesling_spam@cox.net> 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