It's not that the code would be trickier, it'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.
There'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. On Thu, Feb 18, 2010 at 11:04 AM, Tyler Roscoe <[email protected]> wrote: > 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 <[email protected]> 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. >
_______________________________________________ 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
