<div class="gmail_quote">On Sat, Jul 25, 2009 at 6:53 PM, Dominik Szczerba <span dir="ltr"><<a href="mailto:dominik@itis.ethz.ch">dominik@itis.ethz.ch</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;">
When debugging a MSVC target I get a complaint about missing DLL's. Of<br>
course if I 1) copy all required DLL's to the system folder, or 2) copy<br>
the exe along with all the DLL's to one separate folder - all works. But<br>
it's an obvious hassle. How can I run my executables in-place like on<br>
linux where the lib paths are known (thanks to the linker flags)? Have I<br>
forgotten anything in the cmake input?</blockquote><div><br>The commands below will cause all of your generated DLLs & EXEs to
be dumped into a single folder called
"bin" in your toplevel directory unless you're using VS in which case
by default it will be bin/Debug/* or bin/Release/* etc. Import
libraries static or shared will get dumped in a "lib" folder. If
you're using CMake with a WIN32 project that creates DLLs, you pretty
much have to set these variables IMHO for things to be usable.<br>
<br>set(CMAKE_RUNTIME_OUTPUT_<div>DIRECTORY ${CMAKE_BINARY_DIR}/bin)<br>set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)<br>set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BIINARY_DIR}/bin)<br><br>See...<br><a href="http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:RUNTIME_OUTPUT_DIRECTORY" target="_blank">http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:RUNTIME_OUTPUT_DIRECTORY</a><br>
<a href="http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:ARCHIVE_OUTPUT_DIRECTORY" target="_blank">http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:ARCHIVE_OUTPUT_DIRECTORY</a><br><a href="http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LIBRARY_OUTPUT_DIRECTORY" target="_blank">http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LIBRARY_OUTPUT_DIRECTORY</a><br>
<br>===<br><br>Also as an aside in case you haven't come across it yet,
I highly recommend a tool called Dependency Walker for investigating
DLL dependencies.<br><br>===<br><br>To
answer your other question, one technique you can use is called Delay
Loaded DLLs (/DELAYLOAD). I have used it before on a limited basis
with some success although it is a bit finicky to setup error handling
for it. It can be made to work if you know exactly where a DLL is on
the hard drive/drives but that is generally a guess at best so you
might not be able to rely on it. It might be worth a look though.<br><br>I
think generally people use the "copy all DLLs to one folder" approach
unless you're dealing with a well maintained system provided shared
library like DirectX. One of the downsides to Windows & DLL hell :(<br></div><br><br></div></div>-- <br>Philip Lowman<br>