<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 27, 2017 at 10:06 AM, Neil Carlson <span dir="ltr"><<a href="mailto:neil.n.carlson@gmail.com" target="_blank">neil.n.carlson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Sun, Nov 26, 2017 at 12:42 PM, Craig Scott <span dir="ltr"><<a href="mailto:craig.scott@crascit.com" target="_blank">craig.scott@crascit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Please post your CMakeLists.txt so we can see how you've got the fixtures and tests defined.</div></blockquote><div><br></div></span><div>Here's what I've got (I put the run test first to verify that the reordering takes place):</div><div><br></div><div>add_test(NAME intel-20171126-run COMMAND intel-20171126)</div><div>set_tests_properties(intel-<wbr>20171126-run PROPERTIES PASS_REGULAR_EXPRESSION "pass")</div><div>set_tests_properties(intel-<wbr>20171126-run PROPERTIES FIXTURES_REQUIRED foo)</div><div><br></div><div>add_executable(intel-20171126 EXCLUDE_FROM_ALL intel-20171126.f90)<br></div><div><div>add_test(NAME intel-20171126</div><div> COMMAND ${CMAKE_COMMAND} --build . --target intel-20171126 --config $<CONFIGURATION></div><div> WORKING_DIRECTORY ${CMAKE_BINARY_DIR})</div><div>set_tests_properties(intel-<wbr>20171126 PROPERTIES FIXTURES_SETUP foo)</div></div><div><br></div><div>After posting my question, I manually created the "executable" ('touch intel-20171126`)</div><div>and re-ran ctest. Sure enough, that time I didn't get the long message spew about</div><div>being able to find the executable, but instead a 1-line message, which is what I had</div><div>expected to see originally</div><div><br></div><div><div> Start 2: intel-20171126</div><div> 1/13 Test #2: intel-20171126 ...................***Failed 0.15 sec</div><div> Start 1: intel-20171126-run</div><div>Failed test dependencies: intel-20171126</div><div> 2/13 Test #1: intel-20171126-run ...............***Not Run 0.00 sec</div></div><div><br></div></div></div></div>
</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks, that makes the situation clear. I've traced through the CTest source and I think the logic can be improved. I've created an issue for this in the bug tracker here:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://gitlab.kitware.com/cmake/cmake/issues/17514">https://gitlab.kitware.com/cmake/cmake/issues/17514</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I'll look into a fix, but for now that bug report includes a workaround you can use in the meantime.</div><div class="gmail_extra"><br></div><div class="gmail_extra">On a side note, triggering parts of the build when running tests may seem like a convenient solution, but be aware it has some less obvious gotchas. If you are doing this with more than one test, multiple tests might try and build simultaneously. If the things being built share any common dependencies, the two builds may interfere with each other and overwrite each other's files, etc. In the case of parallel builds, multiple build invocations may result in excessive load due to too many tasks running at once. This can cause out of memory issues if compiling or linking particularly big files. If you want to be sure these things can't happen, you may want to force such tests to run serially to guarantee that they are the only build job:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><font face="monospace, monospace">set_tests_properties(intel-20171126 PROPERTIES RUN_SERIAL YES)</font></div><div class="gmail_extra"><br></div>If you are confident that you can guarantee that you know all the test cases that must not run simultaneously, you can use the RESOURCE_LOCK test property instead to only make those specific tests run not at the same time as each other. This will allow other harmless tests to run concurrently with a build test case, leading to more efficient test execution when parallel testing is enabled.<br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a href="https://crascit.com" target="_blank">https://crascit.com</a><br></div></div></div></div></div></div></div>
</div></div>