I apologise if this is not the right list (I was undecided between this and ctest AT <a href="http://cmake.org">cmake.org</a>).<br><br>I learned about the ctest(PARTS addition to cmake 2.7.2x when I read this article <a href="http://www.kitware.com/products/html/CDashSubprojects.html">http://www.kitware.com/products/html/CDashSubprojects.html</a> and I found it an useful and interesting feature.<br>

I decided to put it to use although my projects are so small that the benefits of a staggered submission is negligible compare to the legacy bulk submission with the plain old ctest_submit() command.<br><br>I updated my <u>Nightly</u> ctest script to perform a ctest_submit of the corresponding step that was just completed. The work flow is standard (Update, Configure, Build) and my submission sequence was: Notes, Update, Configure, Build.<br>

<br>When I looked at CDash, I found that the Build was the only step correctly visualized and no trace of Note, Update, or Configure.<br>As puzzling as it was, I tried a few times, modified a few things, and eventually ended up using ctest_submit(PARTS Notes Update Configure Build) which worked, instead of the single steps submissions.<br>

When analysing the output of ctest with -VV, I noticed that the Build.xml file was submitted first, no matter what the ordering of the parameters for the PARTS parameter was: that didn't tell me much, initially.<br><br>

Moving on, I tried breaking down the ctest_submit back into the single steps pieces to experiment a little.  I eventually came to the conclusion that the Build step must be submitted first in order for the others to appear correctly on the dashboard.<br>

<br>Having access to the actual CDash mysql database, I queried the entries by submitting the steps one by one manually.  It seems to me (although I must admit neither I looked at the php code too well nor I am an expert, therefore I might be completely out of track) that the entries in the index.php?project=PROJECT_NAME page all refer back to the build IDs from the build table of the database.  I found the 2 build2update and build2note tables to be the only way one can correlate a build ID to an update ID and a note, respectively, while the configure table stores the buildid information.<br>

<br>I am wondering if this speaks of CDash needing a build ID available (and therefore an entry in the build table as provided by the Build step) prior to submitting Notes, Update, and/or Configure steps to be able to cross-correlate the info correctly?<br>

If so, could there be a workaround consisting of perhaps submitting an stub Build step first to allow any ordering of the submit steps (the actual Build step would come later in the game and perhaps overwrite the previous Build info used as stub?  Would that even be possible?<br>

<br>I am looking forward to hearing your thoughts.<br>Thanks you and Regards,<br><br clear="all">Michele Caramello<br><span style="color:rgb(0,0,153)">Software Testing Engineering Manager,</span><br><span style="color:rgb(0,0,153)">MotionProcessing
 Business Unit</span><b><span style="color:navy"><br>Inven</span></b><b><span style="color:rgb(153,51,0)">Sense</span></b><b><span style="color:rgb(0,0,153)">, Inc.</span></b><span style="color:rgb(0,0,153)"><b><br></b>(O) 408 - 988 -
 7339 x126</span><span style="color:rgb(0,0,153)"><br>Email: </span><a href="mailto:mcaramello@invensense.com" target="_blank">mcaramello@invensense.com</a> <br>