|
|
Boost Interest : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-06-17 11:20:11
On Mon, Jun 16, 2008 at 5:38 PM, KSpam <keesling_spam_at_[hidden]> 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