[CMake] CTEST_UPDATE_COMMAND vs sparse working copy (was Re: continuous integration with CMake)

[Tyler Roscoe]

I've got a preliminary Continuous Integration system up and running
based on the scripts Bill pointed me to. Thanks Bill!

I have some questions about this setup. Let me know if you think I would
get better responses on the CDash list. I'm going to break up these
questions into separate posts to hopefully make ensuing discussion
easier to follow in the mailing list archives.

- CTEST_UPDATE_COMMAND vs sparse working copy

For our project, we use Subversion and sparse working copies
(http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html).

A quick summary: Our repo looks like this:

common/
projectA/
projectB/
projectC/
legacystuff/

We use sparse working copies so that we can check out common/ and
projectA/ without checking out the unrelated projectB/, projectC/, and
legacystuff/ directories. Running svn update in a working copy
configured this way only pulls changes in the desired modules (common/
and projectA/).

The Update phase of CTest doesn't understand sparse directories so it
reports all changes and kicks off a build for all commits to the repo
instead of just the commits in the directories I actually have checked
out in my working copy.

Does anyone else use sparse directories with CTest/CDash? Ideas on how
to make it work? Do I need to write a replacement for "svn update" that
only reports changes I care about? Do I need to hack
CTest/cmCTestSVN.cxx to add support for a sparse directory mode?

Thanks,
tyler

On Fri, Dec 04, 2009 at 01:07:23PM -0500, Bill Hoffman wrote:
> Tyler Roscoe wrote:
> >On Fri, Dec 04, 2009 at 12:09:09PM -0500, Bill Hoffman wrote:
> The build scripts for CMake can be found on CDash itself, for example:
> 
> http://www.cdash.org/CDash/viewNotes.php?buildid=485762
> 
> For each dashboard on the CMake dashboard if you click on the notes for 
> the build you can see the script that was used to drive the build.
> 
> Here is the .bat file that is run for a scheduled task on that machine:
> 
> 
> $ cat dash2win64.bat
> setlocal
> rem Update clapack driver script from clapck
> pushd c:\Dashboards\clapack
> svn up clapack_build.cmake
> rem Run the clapack driver script
> "c:\Program Files (x86)\CMake 2.8\bin\ctest.exe" -C Release -S 
> clapack_build.cmake -VV -O clapack.log
> popd
> endlocal
> 
> call C:\cygwin\bin\bash.exe --login 
> c:/Dashboards/DashboardScripts/dash2win64cygwin.sh
> 
> "c:\Program Files (x86)\CMake 2.8\bin\ctest.exe" -C Release -S 
> dash2Win64_cmake_vs10.cmake -O cmake_vs10.log
> "c:\Program Files (x86)\CMake 2.8\bin\ctest.exe" -C Release -S 
> dash2Win64_cmake_vs10_x64.cmake -O cmake_vs10_x64.log
> 
> setlocal
> call "C:\Program Files (x86)\Microsoft Visual Studio 
> 10.0\VC\bin\vcvars32.bat"
> "c:\Program Files (x86)\CMake 2.8\bin\ctest.exe" -C Release -S 
> dash2Win64_cmake_nmake10.cmake -O cmake_nmake10.log
> endlocal
> 
> setlocal
> call "C:\Program Files (x86)\Microsoft Visual Studio 
> 10.0\VC\bin\amd64\vcvars64.bat"
> "c:\Program Files (x86)\CMake 2.8\bin\ctest.exe" -C Release -S 
> dash2Win64_cmake_nmake10_x64.cmake -O cmake_nmake10_x64.log
> endlocal
> 
> "c:\Program Files (x86)\CMake 2.8\bin\ctest.exe" -C Release -S 
> dash2win64_libarchive_vs9.cmake -VV > libarchive_vs9.log 2>&1
> "c:\Program Files (x86)\CMake 2.9\bin\ctest.exe" -C Release -S 
> dash2win64_cmake_icl11_32.cmake -VV > cmake_icl11_32.log 2>&1
> "c:\Program Files (x86)\CMake 2.9\bin\ctest.exe" -C Release -S 
> dash2win64_cmake_icl11_64.cmake -VV > cmake_icl11_64.log 2>&1