On Mon, Jun 21, 2010 at 10:53 AM, Convey, Christian J CIV NUWC NWPT <span dir="ltr"><<a href="mailto:christian.convey@navy.mil">christian.convey@navy.mil</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">
</div></div>Thanks, that does help. Could you tell me if the following<br>
approach constent with what you guys intended?<br>
<br>
I want some parts of "CTestTestfile.cmake" to be automatically generated from the CMakeLists.txt files in my source directory tree.<br>
<br>
OTOH, I also want to supply some additional information ctest. For example, 'set(CTEST_BUILD_NAME "myBuildName")'.<br>
<br>
So I do this:<br>
<br>
1. Have a permanent (e.g., non-generated) file<br>
"MyCTestScript.cmake" with the following content:<br>
<br>
INCLUDE("CTestTestfile.cmake")<br>
SET(CTEST_BUILD_NAME "myBuildName")<br>
<br>
2. When I want to run tests, I use this command:<br>
ctest -s MyCTestScript.cmake -D Nightly<br>
<font color="#888888"><br></font></blockquote><div> </div><div>I don't think that looks right. CTestTestfile.cmake is an internal, generated file; I can't think of any circumstance where you'd want to be including it directly. It is used *by* ctest to determine what tests to run, but it is not a "ctest script".<br>
<br>I also don't think (although I'm less sure) that you can use both -S and -D on the command line at the same time. They're exclusive options.<br><br>David is right; it's confusing because ctest can be used in several different ways. I think it's actually much worse than he says, because as far as I can tell, ctest can be used in four completely different and mutually incompatible ways, each with their own idiosyncrasies. To make things worse, two of the ways are actually invoked with the same arguments!<br>
<br>1. "ctest" by itself (when run from a binary directory) serves as a simple test harness. It executes test cases previously configured by cmake and reports on the results.<br><br>2. "ctest -D" serves as an "automatic dashboard". The term "dashboard", IMHO, is a terrible one, but what it means is that it will perform a pre-programmed set of operations, chosen from the set of Update, Configure, Build, Test, Coverage, and Submit (upload results to a dashboard). The set of operations it performs, and some details about how they are performed, is determined by the parameter to -D: Experimental, Continuous, Nightly. You have some amount of control over which steps get run using the -T option.<br>
<br>3. "ctest -S" can run a simple CTest script, which is basically a "semi-automatic dashboard". In this kind of script (sometimes called "old-style ctest script", you can set up some variables to modify how the dashboard process is run. This is, again IMHO, a badly thought-out feature, because it still does a lot of things automatically and the variables which you can set to modify the behaviour are quirky and poorly-documented. It really is in no meaningful sense a "script".<br>
<br>4. Finally, "ctest -S" can also run a "new-style CTest script". In this kind of script, you have complete control over what happens - you don't even have to "run a dashboard", but can do pretty much anything you want in whatever order you want. The magic which makes a script a "new-style CTest script" is that it uses the functions ctest_start(), ctest_configure(), etc.<br>
<br></div></div><br>Anyway, that was probably a lot more than you wanted to know at this time, but hopefully it will serve some value in future. Meanwhile, I suspect there's probably a straightforward way to do what you actually want to do, I'm just afraid I don't know what it is that you want to do. :)<br>
<br>Ceej<br>aka Chris Hillery<br>