As I was forced to remove the whole tree (as reported in the other thread) this did not work for me. But now as the problem seems (temporarlily :) gone maybe I will give it a try. Still, if the build tree gets invalid and must be re-created the procedure will have to be repeated. Maybe I should once look into the "install" stuff in cmake...
-- Dominik On Sun, 2009-07-26 at 08:33 -0400, Michael Jackson wrote: > 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 [email protected] > 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 > >> <[email protected]> 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 > > _______________________________________________ > 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 > _______________________________________________ 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
