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

[Tyler Roscoe]

On Thu, Feb 18, 2010 at 11:21:39AM -0500, David Cole wrote:
> It's not that the code would be trickier, it's that the CDash database
> schema only supports one view of a repository in terms of generating correct
> links on its update report pages. So even if ctest allowed you to do this,
> CDash would not produce correct output.
> 
> There's a lot *more* work to be done to get updates from multiple
> repositories or multiple paths within one repository working all the way
> through the ctest/cdash workflow.

David can you expand on this? I'm looking at:
http://www.cdash.org/CDash/viewUpdate.php?buildid=542789

I could understand if there are issues with showing files from multiple
repositories since (among other things) there is only one entry per
project for a viewer URL. But what are the complications preventing
update/log information coming from multiple modules in a single
repository?

Looking at the Update.xml, it all seems reasonably straightforward:

<?xml version="1.0" encoding="UTF-8"?>
<Update mode="Client" Generator="ctest-2.8.0">
    <Site>blewett</Site>
    <BuildName>win64-vs2005</BuildName>
    <BuildStamp>20100217-2218-Continuous</BuildStamp>
    <StartDateTime>Feb 17 14:19 Pacific Standard Time</StartDateTime>
    <StartTime>1266445158</StartTime>
    <UpdateCommand>&quot;C:/Program Files (x86)/CollabNet Subversion/svn.exe&quot; &quot;update&quot; &quot;--non-interactive&quot;</UpdateCommand>
    <UpdateType>SVN</UpdateType>
    <Directory>
        <Name>shelves/michael/UnicodeCharacterSupport/base/winutil</Name>
        <Updated>
            <File>BuildLibs.bat</File>
            <Directory>shelves/michael/UnicodeCharacterSupport/base/winutil</Directory>
            <FullName>shelves/michael/UnicodeCharacterSupport/base/winutil/BuildLibs.bat</FullName>
            <CheckinDate>2010-02-17T22:06:32.435488Z</CheckinDate>
            <Author>michael</Author>
            <Log>Copy icu4c libraries into development bin directory.</Log>
            <Revision>8422</Revision>
            <PriorRevision>8418</PriorRevision>
        </Updated>
    </Directory>
    <Directory>
        <Name>shelves/tylermr/cdashscripts</Name>
        <Updated>
            <File>cmake_common.cmake</File>
            <Directory>shelves/tylermr/cdashscripts</Directory>
            <FullName>shelves/tylermr/cdashscripts/cmake_common.cmake</FullName>
            <CheckinDate>2010-02-17T22:15:24.508203Z</CheckinDate>
            <Author>tylermr</Author>
            <Log>Increase max errors and warnings reported during Build phase.</Log>
            <Revision>8423</Revision>
            <PriorRevision>8418</PriorRevision>
        </Updated>
    </Directory>
    <Directory>
        <Name>trunk/base</Name>
        <Updated>
            <File>system0.cpp</File>
            <Directory>trunk/base</Directory>
            <FullName>trunk/base/system0.cpp</FullName>
            <CheckinDate>2010-02-17T20:26:46.686557Z</CheckinDate>
            <Author>karen</Author>
            <Log>Added ICU copyright to Help About dialog.  Also fixed bad characters in copyright for Abacus library.</Log>
            <Revision>8419</Revision>
            <PriorRevision>8418</PriorRevision>
        </Updated>
    </Directory>
    <EndDateTime>Feb 17 14:20 Pacific Standard Time</EndDateTime>
    <EndTime>1266445227</EndTime>
<ElapsedMinutes>1.1</ElapsedMinutes>
    <UpdateReturnStatus></UpdateReturnStatus>
</Update>

This sample already handles file changes in various directories, so I
don't understand what would be different if there were a few more
directories.

If CDash itself can't handle ctest_update(... APPEND ...), could it work
if I made my build script run the individual updates and cobble together the
resulting individual Update.xmls into a single Update.xml and submitted
that?

Thanks,
tyler

> On Thu, Feb 18, 2010 at 11:04 AM, Tyler Roscoe <tyler at cryptio.net> wrote:
> > On Thu, Feb 18, 2010 at 09:14:05AM -0500, David Cole wrote:
> > > The APPEND option is probably a little more complicated than you think it
> > > is... And it is not "secretly" (or otherwise) added to ctest_update...
> > > CMake, being open source and all, has no secrets. :-)
> >
> > I was just joking about it being secret. I was idly hoping that maybe
> > when APPEND was added to _build and _configure, it was also added to
> > _update but the docs were only updated for _build and _configure. Sounds
> > like this is not the case; bummer.
> >
> > > We need to write some docs or an article that explains how to use
> > "APPEND"
> > > well.
> > >
> > > Every call to ctest_build yields a completely new Build.xml file to send
> > to
> > > CDash. The APPEND option merely tells CDash to append the results to
> > those
> > > already in the database for a given build... it does not actually append
> > > data to the same Build.xml file. Therefore, if you use it, you must also
> > use
> > > piecemeal ctest_submit calls to send each Build.xml file as it's produced
> > > over to CDash before the next call overwrites the Build.xml file. (Things
> > > are getting more complicated as CMake ages.)
> >
> > FWIW this is how I assumed it would work.
> >
> > Is it the case that the underlying code that supports APPEND for _build
> > and _configure would be a lot trickier for the case of _update? If so,
> > why?