[CMake] problems running a windows build exectuable

[Michael Jackson]

I just got in the habit of writing code that copies my 3rd party DLLs  
into the current CMake Binary directory (Like Qt, HDF5.. ). This lets  
me debug my programs with less headaches. Probably not the best/ 
optimal solution but does get the job done. I have some really "scary  
cmake" code if you are interested (optimized for the Qt Libraries)..

_________________________________________________________
Mike Jackson                  mike.jackson at bluequartz.net
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio



On Jul 26, 2009, at 4:08 AM, Dominik Szczerba wrote:

> 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
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake