[CMake] problems running a windows build exectuable

[Dominik Szczerba]

Many thanks for a very detail and equally helpful explanation. Strictly
speaking it does not exactly do what I wanted to achieve (run binaries
in place with correctly linked dll's) but greatly simplifies the
procedure of copying the runtime files to one folder (without it VS just
scatters the files in million separate sub-folders). I will also look
into delayed loading.
many thanks and regards,
Dominik

On Sat, 2009-07-25 at 23:21 -0400, Philip Lowman wrote:
> On Sat, Jul 25, 2009 at 6:53 PM, Dominik Szczerba
> <dominik at itis.ethz.ch> wrote:
>         When debugging a MSVC target I get a complaint about missing
>         DLL's. Of
>         course if I 1) copy all required DLL's to the system folder,
>         or 2) copy
>         the exe along with all the DLL's to one separate folder - all
>         works. But
>         it's an obvious hassle. How can I run my executables in-place
>         like on
>         linux where the lib paths are known (thanks to the linker
>         flags)? Have I
>         forgotten anything in the cmake input?
> 
> 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.
> 
> set(CMAKE_RUNTIME_OUTPUT_
> DIRECTORY ${CMAKE_BINARY_DIR}/bin)
> set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BIINARY_DIR}/bin)
> 
> See...
> http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:RUNTIME_OUTPUT_DIRECTORY
> http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:ARCHIVE_OUTPUT_DIRECTORY
> http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:LIBRARY_OUTPUT_DIRECTORY
> 
> ===
> 
> 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.
> 
> ===
> 
> 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.
> 
> 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 :(
> 
> 
> 
> 
> -- 
> Philip Lowman