Boost Interest :
Subject: Re: [Boost-cmake] Labels for known failures
From: Brad King (brad.king_at_[hidden])
Date: 2009-05-18 12:08:59
troy d. straszheim wrote:
> Question #1: How do the settings in the script you posted relate to the
> settings found in $CMAKE_SOURCE_DIR/CTestConfig.cmake? Can they be
The settings in the source tree are project-wide and have CDash submission
information. These are shared by all submitters.
The settings in the ctest scripts are specific to the individual clients.
They control what compiler gets used, what options get built, etc.
> #2: What is the recommended way to handle these cross-platform bits? If
> you just execute 'ctest -D Nightly' in a configured directory, you don't
> need to touch that stuff... since the initial cmake step appears to
> seamlessly figure out what your generator, make command, and update
> commands are, the intention was to configure_file these settings over to
> the binary directory so that the tester's job is:
> 1. checkout source
> 2. run cmake with -DBUILD_REGRESSION_TESTS=ON
> 3. possibly customize a few (simple) variables in a file that was
> generated in step 2 (but not ones involving implementation details of
> cmake/ctest like CTEST_CMAKE_GENERATOR)
> 4. run ctest manually, in a loop, or via cron/Task Scheduler
This can work, but it is a lot of manual effort for a tester. Also,
it is sometimes nice to just wipe the build tree to make sure things
work from a clean state. In that case each tester would have to re-do
OTOH the script method will work even if the tester wipes out the source
tree and build tree. The next time the tests run the script will recreate
> But I'm open to the idea that this doesn't make sense for some reason.
> Your script does make it easier to see all of the configuration in one
> place (very important). So we would maintain one of those scripts per
The vxl project has one central script, and the per-machine details are
configured by a small helper script written by each submitter. The
helper script selects the compiler and sets the environment on each
machine. The latter part cannot be maintained by any one developer
because it is specific to each tester's machine.