On Thu, Feb 18, 2010 at 11:21:39AM -0500, David Cole wrote: > 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.
David can you expand on this? I'm looking at: http://www.cdash.org/CDash/viewUpdate.php?buildid=542789 I could understand if there are issues with showing files from multiple repositories since (among other things) there is only one entry per project for a viewer URL. But what are the complications preventing update/log information coming from multiple modules in a single repository? Looking at the Update.xml, it all seems reasonably straightforward: <?xml version="1.0" encoding="UTF-8"?> <Update mode="Client" Generator="ctest-2.8.0"> <Site>blewett</Site> <BuildName>win64-vs2005</BuildName> <BuildStamp>20100217-2218-Continuous</BuildStamp> <StartDateTime>Feb 17 14:19 Pacific Standard Time</StartDateTime> <StartTime>1266445158</StartTime> <UpdateCommand>"C:/Program Files (x86)/CollabNet Subversion/svn.exe" "update" "--non-interactive"</UpdateCommand> <UpdateType>SVN</UpdateType> <Directory> <Name>shelves/michael/UnicodeCharacterSupport/base/winutil</Name> <Updated> <File>BuildLibs.bat</File> <Directory>shelves/michael/UnicodeCharacterSupport/base/winutil</Directory> <FullName>shelves/michael/UnicodeCharacterSupport/base/winutil/BuildLibs.bat</FullName> <CheckinDate>2010-02-17T22:06:32.435488Z</CheckinDate> <Author>michael</Author> <Log>Copy icu4c libraries into development bin directory.</Log> <Revision>8422</Revision> <PriorRevision>8418</PriorRevision> </Updated> </Directory> <Directory> <Name>shelves/tylermr/cdashscripts</Name> <Updated> <File>cmake_common.cmake</File> <Directory>shelves/tylermr/cdashscripts</Directory> <FullName>shelves/tylermr/cdashscripts/cmake_common.cmake</FullName> <CheckinDate>2010-02-17T22:15:24.508203Z</CheckinDate> <Author>tylermr</Author> <Log>Increase max errors and warnings reported during Build phase.</Log> <Revision>8423</Revision> <PriorRevision>8418</PriorRevision> </Updated> </Directory> <Directory> <Name>trunk/base</Name> <Updated> <File>system0.cpp</File> <Directory>trunk/base</Directory> <FullName>trunk/base/system0.cpp</FullName> <CheckinDate>2010-02-17T20:26:46.686557Z</CheckinDate> <Author>karen</Author> <Log>Added ICU copyright to Help About dialog. Also fixed bad characters in copyright for Abacus library.</Log> <Revision>8419</Revision> <PriorRevision>8418</PriorRevision> </Updated> </Directory> <EndDateTime>Feb 17 14:20 Pacific Standard Time</EndDateTime> <EndTime>1266445227</EndTime> <ElapsedMinutes>1.1</ElapsedMinutes> <UpdateReturnStatus></UpdateReturnStatus> </Update> This sample already handles file changes in various directories, so I don't understand what would be different if there were a few more directories. If CDash itself can't handle ctest_update(... APPEND ...), could it work if I made my build script run the individual updates and cobble together the resulting individual Update.xmls into a single Update.xml and submitted that? Thanks, tyler > 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? _______________________________________________ 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
