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. :-)<div><br></div>
<div>We need to write some docs or an article that explains how to use "APPEND" well.<br><br><div>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.)</div>
<div><br></div><div>Bottom line: there is still work to be done to accomodate these different usage scenarios...</div><div><br></div><div><br></div><div>HTH, (for now)</div><div>David</div><div><br></div><div><br><div class="gmail_quote">
On Wed, Feb 17, 2010 at 7:03 PM, Tyler Roscoe <span dir="ltr"><<a href="mailto:tyler@cryptio.net">tyler@cryptio.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Feb 17, 2010 at 04:16:15PM -0700, Clinton Stimpson wrote:<br>
> On 02/17/2010 03:49 PM, Tyler Roscoe wrote:<br>
> >On Wed, Feb 17, 2010 at 03:16:13PM -0700, Clinton Stimpson wrote:<br>
> ><br>
> >>Have you tried setting CTEST_UPDATE_OPTIONS to contain the extra<br>
> >>arguments for<br>
> >>updating the way you want?<br>
> >><br>
> >This affects the svn update command itself (which is working fine<br>
> >without further adjustment) but does not appear to affect the later svn<br>
> >log and svn status calls which (I assume) are what CTest parses to<br>
> >generate the Update log.<br>
> ><br>
> >Worse news for me: I don't think I can run "svn log projectA/ projectB/"<br>
> >to try to only get logs for those areas I care about because:<br>
> ><br>
> > svn: When specifying working copy paths, only one target may be given<br>
> ><br>
> >(I tried with URLs instead of working copy paths but that didn't work<br>
> >either.)<br>
> ><br>
><br>
> What about multiple ctest_update() calls (one for each sub dir)?<br>
> I've put in a request for that to be handled too.<br>
> <a href="http://public.kitware.com/Bug/view.php?id=8263" target="_blank">http://public.kitware.com/Bug/view.php?id=8263</a><br>
<br>
</div>It seems this would be a solution to my problem (maybe not as elegant as I'd<br>
like since I would have to include information about what a<br>
properly-configured working copy looks like in my build scripts (bad<br>
encapsulation / duplication) but I'll take what I can get :p).<br>
<br>
It looks like this feature has been implemented for ctest_configure()<br>
and ctest_build() via the APPEND option. Any chance it has been secretly<br>
added to ctest_update() but the documentation was forgotten (I'll check<br>
on this tomorrow unless someone happens to know)? If not, how hard would<br>
it be to add this functionality? Theoretically we could work from the<br>
examples in ctest_build() and ctest_update(), which would simplify the<br>
chore.<br>
<font color="#888888"><br>
tyler<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br></div></div>