Brad King wrote:
The script can be written totally outside the source and build trees.
If written properly it can do the initial checkout and create the build
tree. A standalone script I use to do one of CMake's builds appears below.
You can also create project-specific helper scripts like this one:
[snip]
SET(CTEST_CMAKE_GENERATOR "Unix Makefiles")
[snip]
SET(CTEST_CHECKOUT_COMMAND
"/usr/bin/cvs -q -z3 -d:pserver:anon...@www.cmake.org:/cvsroot/CMake
co -d CMakeSun -D yesterday CMake")
[snip]
MAKECOMMAND:STRING=/usr/bin/make -i -j2
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
combined?
#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
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
platform?
-t
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
