<div dir="ltr"><div class="gmail_extra">My way of dealing with this problem is similar to other people here:</div><div class="gmail_extra"><br></div><div class="gmail_extra"> 1. I have a separate Python post-build script designed to be driven through command line.</div>
<div class="gmail_extra">     This script read somewhere the list of direct binary dependencies of the target[1] and copy them in the</div><div class="gmail_extra">     output directory. The script also check that the dependency file is not already in that place.</div>
<div class="gmail_extra"> 2. I have CMake scripts that provide project definition macros which does the actual work</div><div class="gmail_extra">     of setting up the projects depending on the kind but it's all specific to my project/domain.</div>
<div class="gmail_extra"> 3. The CMake scripts will add a custom post-build command calling the Python post-build script with the correct arguments for the specific target.</div><div class="gmail_extra"> 4. Therefore, after build of any of MY projects of my Visual Studio solution, the post build script copy the </div>
<div class="gmail_extra">      necessary dependencies in what I call the "install" directory which is settup in a way similar to a normal install </div><div class="gmail_extra">      of the application. This happen after the target is generated into it's output directory; so first the project is compiled</div>
<div class="gmail_extra">      with it's dependencies, then all these binaries are copied in the "install" directory.</div><div class="gmail_extra"> 5. After generating my VS solution using CMake, the first thing I do is to change the debug paths of the executables projects</div>
<div class="gmail_extra">     so that debugging them will actually run the binaries in the "install" direction. This is because I want that directory to be </div><div class="gmail_extra">     as close as the final directory, so I can catch issues with missing dlls immediately (and in practice it helped a lot catch any kind of dependencies and configuration issues)</div>
<div class="gmail_extra">     It's also easier to generate a test build this way.     </div><div class="gmail_extra"><br></div><div class="gmail_extra">Note that:</div><div class="gmail_extra"><br></div><div class="gmail_extra">
 - I don't want to polluate the developer's PATH with anything from the dependencies, which is one reason why I have so many constraints</div><div class="gmail_extra">   (that CMake only solve in half)</div><div class="gmail_extra">
 - I want to be able to debug most of my dependencies (for a lot of reasons) so I NEED to have their sources (except if I have no choice)</div><div class="gmail_extra">   and I NEED to have their sources debuggable and visible from the debugger.</div>
<div class="gmail_extra"> - Why can't I use the install command from CMake? My understanding is that it's used to install the application in the system, which is NOT what I want to do here.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">It's one of the reasons I have found CMake frustrating, there is not much helping with these kind of contexts.</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] I didn't find a way to provide the dependencies automatically because some dlls are simply not part of the project,</div>
<div class="gmail_extra">     So I have a specific file with all the direct binary dependencies explicitely listed for each target.</div></div>