<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 26, 2014 at 8:04 AM, Klaim - Joël Lamotte <span dir="ltr"><<a href="mailto:mjklaim@gmail.com" target="_blank">mjklaim@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div><br></div><div>Install can be targeted anywhere doesn't have to be 'into the the system'. With Install rules it becomes just one minor step more to add packaging to get an installer for distribution.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"></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>
<br>--<br>
<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br></blockquote></div><br></div></div>