It&#39;s not that the code would be trickier, it&#39;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.<div>
<br></div><div>There&#39;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.</div><div><br><br><div class="gmail_quote">
On Thu, Feb 18, 2010 at 11:04 AM, Tyler Roscoe <span dir="ltr">&lt;<a href="mailto:tyler@cryptio.net">tyler@cryptio.net</a>&gt;</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 Thu, Feb 18, 2010 at 09:14:05AM -0500, David Cole wrote:<br>
&gt; The APPEND option is probably a little more complicated than you think it<br>
&gt; is... And it is not &quot;secretly&quot; (or otherwise) added to ctest_update...<br>
&gt; CMake, being open source and all, has no secrets. :-)<br>
<br>
</div>I was just joking about it being secret. I was idly hoping that maybe<br>
when APPEND was added to _build and _configure, it was also added to<br>
_update but the docs were only updated for _build and _configure. Sounds<br>
like this is not the case; bummer.<br>
<div class="im"><br>
&gt; We need to write some docs or an article that explains how to use &quot;APPEND&quot;<br>
&gt; well.<br>
&gt;<br>
&gt; Every call to ctest_build yields a completely new Build.xml file to send to<br>
&gt; CDash. The APPEND option merely tells CDash to append the results to those<br>
&gt; already in the database for a given build... it does not actually append<br>
&gt; data to the same Build.xml file. Therefore, if you use it, you must also use<br>
&gt; piecemeal ctest_submit calls to send each Build.xml file as it&#39;s produced<br>
&gt; over to CDash before the next call overwrites the Build.xml file. (Things<br>
&gt; are getting more complicated as CMake ages.)<br>
<br>
</div>FWIW this is how I assumed it would work.<br>
<br>
Is it the case that the underlying code that supports APPEND for _build<br>
and _configure would be a lot trickier for the case of _update? If so,<br>
why?<br>
<div><div></div><div class="h5"><br>
&gt; On Wed, Feb 17, 2010 at 7:03 PM, Tyler Roscoe &lt;<a href="mailto:tyler@cryptio.net">tyler@cryptio.net</a>&gt; wrote:<br>
&gt; &gt; On Wed, Feb 17, 2010 at 04:16:15PM -0700, Clinton Stimpson wrote:<br>
&gt; &gt; &gt; On 02/17/2010 03:49 PM, Tyler Roscoe wrote:<br>
&gt; &gt; &gt; &gt;On Wed, Feb 17, 2010 at 03:16:13PM -0700, Clinton Stimpson wrote:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt;Have you tried setting CTEST_UPDATE_OPTIONS to contain the extra<br>
&gt; &gt; &gt; &gt;&gt;arguments for<br>
&gt; &gt; &gt; &gt;&gt;updating the way you want?<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;This affects the svn update command itself (which is working fine<br>
&gt; &gt; &gt; &gt;without further adjustment) but does not appear to affect the later svn<br>
&gt; &gt; &gt; &gt;log and svn status calls which (I assume) are what CTest parses to<br>
&gt; &gt; &gt; &gt;generate the Update log.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;Worse news for me: I don&#39;t think I can run &quot;svn log projectA/ projectB/&quot;<br>
&gt; &gt; &gt; &gt;to try to only get logs for those areas I care about because:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;     svn: When specifying working copy paths, only one target may be<br>
&gt; &gt; given<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;(I tried with URLs instead of working copy paths but that didn&#39;t work<br>
&gt; &gt; &gt; &gt;either.)<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; What about multiple ctest_update() calls (one for each sub dir)?<br>
&gt; &gt; &gt; I&#39;ve put in a request for that to be handled too.<br>
&gt; &gt; &gt; <a href="http://public.kitware.com/Bug/view.php?id=8263" target="_blank">http://public.kitware.com/Bug/view.php?id=8263</a><br>
&gt; &gt;<br>
&gt; &gt; It seems this would be a solution to my problem (maybe not as elegant as<br>
&gt; &gt; I&#39;d<br>
&gt; &gt; like since I would have to include information about what a<br>
&gt; &gt; properly-configured working copy looks like in my build scripts (bad<br>
&gt; &gt; encapsulation / duplication) but I&#39;ll take what I can get :p).<br>
&gt; &gt;<br>
&gt; &gt; It looks like this feature has been implemented for ctest_configure()<br>
&gt; &gt; and ctest_build() via the APPEND option. Any chance it has been secretly<br>
&gt; &gt; added to ctest_update() but the documentation was forgotten (I&#39;ll check<br>
&gt; &gt; on this tomorrow unless someone happens to know)? If not, how hard would<br>
&gt; &gt; it be to add this functionality? Theoretically we could work from the<br>
&gt; &gt; examples in ctest_build() and ctest_update(), which would simplify the<br>
&gt; &gt; chore.<br>
</div></div></blockquote></div><br></div>