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 <ty...@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 >
_______________________________________________ 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