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

[David Cole]

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. :-)

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.)

Bottom line: there is still work to be done to accomodate these different
usage scenarios...


HTH, (for now)
David


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.
>
> tyler
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100218/252ffe71/attachment.htm>