<div dir="ltr">This is all handled by install.<div>Plugins get installed in their correct directory</div><div>resources; data files etc get installed in their correct directory...</div><div>each type of target is handled with INSTALL( TARGET ) but you get 3 destinations; RUNTIME (exe), LIBRARY(.dll,.so) and ARCHIVE (.lib,.a) ; they claim that runtime is .dll on windows; but this is just not true; if library is set, DLL goes to that path...</div><div>but otherwise...</div><div><br></div><div>Sounds really like you're working to build a package, which install is intended to do. With a few more cmake commands after building install rules, can use package command and build an installable.... NSIS works good for windows; I know there's MAC dmz(?) support also... but the first thing you'd do is build a directory structure. </div><div><br></div><div>Again INSTALL doesn't have to be 'install' but can be 'write to this relative directory, this directory structure' </div><div><br></div><div>Then you just have to right-click on the project, edit debugging properties, and browse to the installed location.</div><div><br></div><div>CMAKE is really fast in visual studio if you have a large project of lots of targets and only a few rebuild and copy.</div><div><br></div><div>The INSTALL output can be really noisy, but there's a new setting that can be applied at the top of the root cmake script file...</div><div><div>set( CMAKE_INSTALL_MESSAGE "LAZY" )</div></div><div><br></div><div>that will cut down on the output and only show what was actually updated.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 9, 2014 at 4:34 PM, Eric Wing <span dir="ltr"><<a href="mailto:ewmailing@gmail.com" target="_blank">ewmailing@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 class="HOEnZb"><div class="h5">On 12/9/14, Walter Gray <<a href="mailto:chrysalisx@gmail.com">chrysalisx@gmail.com</a>> wrote:<br>
> Hey all,<br>
> I'm working on a module that will allow me to automatically copy all the<br>
> required .dll files as defined by well-formed import library targets to<br>
> the appropriate location (same folder for windows, Frameworks folder for<br>
> OSX bundle, ect). I've got the code that scans an executable's<br>
> INTERFACE_LINK_LIBRARIES property recursively to find all such shared<br>
> library, however I'm running into a small problem. I really like using<br>
> file globbing in higher level source directories to add all appropriate<br>
> sub-directories, but this means that sometimes a dependency will not be<br>
> fully defined yet. This is normally fine since these things are usually<br>
> resolved at *generation* time, but since I'm doing a manual traversal of<br>
> the list of link libraries at config time that's not really acceptable.<br>
> I realize I could just not do the globbing and just make sure the<br>
> directories were setup in the correct order, but I really don't like<br>
> making the add_subdirectory calls order dependent.<br>
><br>
> One solution I've come up with is to add the targets I want to do this<br>
> to to a global list, then iterate over that list as the last step in my<br>
> top-level cmake lists file, but that has the issue that I can no longer<br>
> use add_custom_command on those targets at that point. I'm wondering 3<br>
> things:<br>
><br>
> 1)What is the reasoning behind not allowing add_custom_command on<br>
> targets not defined in the current directory? Especially now that SOURCE<br>
> can be modified, the restriction seems very arbitrary.<br>
><br>
> 2)How stupid would it be to reserve the command using something like<br>
> add_custom_command(TARGET ${target} POST_BUILD COMMAND<br>
> $<TARGET_PROPERTY:COPY_SHARED_LIBS_COMMAND>)<br>
> then use set_property(TARGET ${target} APPEND PROPERTY<br>
> COPY_SHARED_LIBS_COMMAND to add more copy steps to the command?<br>
><br>
> 3) Am I completely missing something and there's already a totally well<br>
> supported way of making sure that an executable's shared library<br>
> dependencies end up in the correct directory? I couldn't find a really<br>
> satisfactory answer on stack overflow or the archives.<br>
><br>
> Thanks!<br>
><br>
<br>
<br>
</div></div>I think this is a good idea if you can pull it off. I recently wrote a<br>
lot of excruciating CMake code to do this for me. (I also was dealing<br>
with resource and plugin code which shares similar issues.) This<br>
actually took me a very long time to implement and it would be better<br>
if CMake handled this automatically. Here is a list of ideas that I<br>
needed to deal with:<br>
<br>
- My motivation was to build a runnable product when you build. On<br>
Visual Studio, you can't run through the debugger because none of the<br>
.dlls are in place. Similarly on Mac, iOS, Android, and now WinRT,<br>
there is no separation/distinction between compiling the executable<br>
and packaging the contents. This is in my opinion of the most<br>
problematic design issues in CMake. I also strongly feel that having<br>
to run the install target is very wrong because it violates the normal<br>
workflow on all these platforms and you also end up developing/testing<br>
something different than what you ship to testers/users.<br>
<br>
- The fix_bundle_utils didn't work for me because it did stuff in the<br>
install stage (too late). Also, it didn't handle my usage of Mac<br>
@rpath (not sure if that was fixed since) so I gave up on it early.<br>
<br>
<br>
- I needed an explicit declaration mechanism to describe which<br>
libraries needed to be bundled (or which did not). Some are system<br>
libraries while others need to be redistributed with the app. And some<br>
might be static libraries which you don't copy. (A .lib/.dll on Visual<br>
Studio and a .framework on iOS is ambiguous to whether they are static<br>
or dynamic.)<br>
<br>
- There was also both implicit knowledge about where they go for<br>
each platform (had to make decisions about Linux and RPATH_ORIGIN),<br>
and also made decisions when they were nested in subdirectories. (I<br>
preserve the layout.)<br>
<br>
- For Visual Studio, that explicit mechanism had to be aware that<br>
you link with .libs, but copy the .dll.<br>
<br>
- I didn't do an explicit scan of the libraries for dependencies<br>
for multiple reasons. One important reason to me though is I want the<br>
build to be as fast as possible (ideally on par with Xcode normally<br>
does which is apples-to-apples in this case).<br>
<br>
- I don't think scanning INTERFACE_LINK_LIBRARIES is<br>
sufficient because it won't capture what libraries each of those might<br>
depend on. For example, I deal with a pre-build SDL_image library on<br>
Windows which depends on libtiff, libjpeg, libpng. libpng then in turn<br>
depends on zlib.<br>
<br>
- The complexity of recursively walking the dependencies,<br>
and then also knowing which ones are system supplied libraries and<br>
which are not is really hard, which is another reason I went the<br>
explicit declaration route. (And shipping Linux binaries is a<br>
nightmare; you have to make hard decisions about what is a system<br>
library and what you need to need to ship yourself.)<br>
<br>
- Mac/iOS framework copies were a pain because they are bundles<br>
(directory structures) and also have symlinks, both of which CMake<br>
does not support well for copying. I ended up using rsync on those<br>
platforms.<br>
<br>
- rsync had a nice advantage of resyncing if the source<br>
framework/library changed and its a very efficient copy.<br>
<br>
- But rsync got me into performance overhead when I introduced<br>
codesigning because codesigning always changes the library, causing<br>
the library to be resynced with the original and then needing to<br>
codesign again. (Codesigning is a slow operation.)<br>
<br>
- I also need an explicit mechanism that signed libraries/plugins.<br>
This signing MUST happen before Xcode tries to do the final<br>
codesigning for your application. (I don't know if POST_BUILD is too<br>
late or not.)<br>
<br>
- I was thinking that it would be nice if there was a CMake way to<br>
declare which things need to be codesigned too. (Some kind of<br>
SET_PROPERTIES thing.)<br>
<br>
- In some cases, libraries get nested into subdirectories and this<br>
information needs to be preserved for packing. Traversing the file<br>
hierarchy relative to the bundles and preserving this information was<br>
really nasty. I needed data structures in CMake and ended up doing<br>
really nasty string tricks since everything is a string in CMake.<br>
<br>
<br>
- I needed to handle things like rpath (Linux, Mac).<br>
<br>
<br>
- Note, almost all this stuff I ended up re-applying for plugins and resources.<br>
<br>
- I ended up dealing with icons, launch screens, application<br>
manifests, sandboxing entitlements as completely separate entities.<br>
<br>
<br>
There's probably a lot more.<br>
<br>
<br>
Thanks,<br>
Eric<br>
<span class="HOEnZb"><font color="#888888">--<br>
Beginning iPhone Games Development<br>
<a href="http://playcontrol.net/iphonegamebook/" target="_blank">http://playcontrol.net/iphonegamebook/</a><br>
</font></span><div class="HOEnZb"><div class="h5">--<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://public.kitware.com/mailman/listinfo/cmake" target="_blank">http://public.kitware.com/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br></div>