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

[Tyler Roscoe]

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?

> On Wed, Feb 17, 2010 at 7:03 PM, Tyler Roscoe <tyler at cryptio.net> wrote:
> > On Wed, Feb 17, 2010 at 04:16:15PM -0700, Clinton Stimpson wrote:
> > > On 02/17/2010 03:49 PM, Tyler Roscoe wrote:
> > > >On Wed, Feb 17, 2010 at 03:16:13PM -0700, Clinton Stimpson wrote:
> > > >
> > > >>Have you tried setting CTEST_UPDATE_OPTIONS to contain the extra
> > > >>arguments for
> > > >>updating the way you want?
> > > >>
> > > >This affects the svn update command itself (which is working fine
> > > >without further adjustment) but does not appear to affect the later svn
> > > >log and svn status calls which (I assume) are what CTest parses to
> > > >generate the Update log.
> > > >
> > > >Worse news for me: I don't think I can run "svn log projectA/ projectB/"
> > > >to try to only get logs for those areas I care about because:
> > > >
> > > >     svn: When specifying working copy paths, only one target may be
> > given
> > > >
> > > >(I tried with URLs instead of working copy paths but that didn't work
> > > >either.)
> > > >
> > >
> > > What about multiple ctest_update() calls (one for each sub dir)?
> > > I've put in a request for that to be handled too.
> > > http://public.kitware.com/Bug/view.php?id=8263
> >
> > It seems this would be a solution to my problem (maybe not as elegant as
> > I'd
> > like since I would have to include information about what a
> > properly-configured working copy looks like in my build scripts (bad
> > encapsulation / duplication) but I'll take what I can get :p).
> >
> > It looks like this feature has been implemented for ctest_configure()
> > and ctest_build() via the APPEND option. Any chance it has been secretly
> > added to ctest_update() but the documentation was forgotten (I'll check
> > on this tomorrow unless someone happens to know)? If not, how hard would
> > it be to add this functionality? Theoretically we could work from the
> > examples in ctest_build() and ctest_update(), which would simplify the
> > chore.