<div class="gmail_quote">On Mon, Aug 31, 2009 at 1:08 AM, King, Steven R <span dir="ltr"><<a href="mailto:steven.r.king@intel.com">steven.r.king@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I now put all my binaries and libraries in ${CMAKE_BINARY_DIR}/bin as Clint suggested. This caused ctest to fail for lack of knowing where the test binary went. I made this adjustment:<br>
<br>
add_test (<br>
test_my_module<br>
${CMAKE_BINARY_DIR}/bin/test_my_module<br>
)<br>
<br>
which allowed ctest to find the executable. However, the executable still can't find the dll, since ctest runs the test from ${CMAKE_CURRENT_BINARY_DIR} which is apparently not equal to ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}. As we've just belabored, putting the dll in ${CMAKE_CURRENT_BINARY_DIR} is neither easy nor well advised.<br>
<br>
OK, now I'm actually getting worried. Any other ideas, please?</blockquote><div><br>What we do at work is generate the test binaries in CMAKE_RUNTIME_OUTPUT_DIRECTORY as well. This does tend to clutter up that directory but they don't get make installed so it's not a huge issue for us.<br>
<br>You might be able to use the ENVIRONMENT test property to append to the PATH environment variable CMAKE_RUNTIME_OUTPUT_DIRECTORY. This would allow the test binaries (in theory) to find their dependent DLLs while not existing in CMAKE_RUNTIME_OUTPUT_DIRECTORY.<br>
</div></div><br>-- <br>Philip Lowman<br>