<div class="gmail_quote">On Fri, Jan 23, 2009 at 3:37 PM, Robert Dailey <span dir="ltr"><<a href="mailto:rcdailey@gmail.com">rcdailey@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><div class="gmail_quote">On Fri, Jan 23, 2009 at 3:36 AM, Mike Arthur <span dir="ltr"><<a href="mailto:mike@mikearthur.co.uk" target="_blank">mike@mikearthur.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Thursday 22 January 2009 23:26:47 Robert Dailey wrote:<br>
> With all do respect, why does it matter? Yes, in the generated target<br>
> dependencies are handled for me but when I call get_target_property() with<br>
> LINK_INTERFACE_LIBRARIES it only includes the dependencies I specific for<br>
> only that executable target, it does not provide me the transitive<br>
> dependencies. This is a problem for me.<br><br>
</div>It matters because:<br>
a) You're asking for help on a list of mostly volunteers so sometimes we ask<br>
why you're doing something so we can direct you if you've just missed<br>
something in CMake.<br>
b) You may have uncovered a bug in CMake and we'd like to help make CMake<br>
better than it is.</blockquote></div><br></div>Most of the time it is extremely difficult or impossible to express my tone of voice through text. I did not mean for my initial question to sound rude, but if it seemed that way I do apologize. I'm used to the case where people ask "Why are you doing that in the first place" and when I respond they usually retaliate with rude remarks, like "You're doing that completely wrong and it's evil". So I make every effort to avoid such questions because of this.<br>
<br>In any case, the reason why I'm doing this is rather complicated and I could spend a few paragraphs explaining it. However if you are really interested in knowing I don't mind explaining:<br><br>For my specific project, I keep all of my third party dependencies versioned with the source code. So I may have a directory called "project/source", that contains all of my source code, and a directory named "project/third_party" which contains various third party libraries. Using the Boost library as an example on the Windows platform, we would have import libraries located here:<br>
<br>"project/third_party/boost/libs/<lib files here>"<br>
<br>
In the same directory that the import libraries (LIB) files are located
in, we also have the shared library files (DLL). We group them like
this because we want CMake to be able to get a list of import library
dependencies and simply replace the extension with DLL in order to find
the corresponding shared library so that we may copy those DLL files to
the binary output directory, which would be
"CMAKE_BINARY_DIR/bin/<configuration>".<br><br>However, this situation gets a little more complex. Suppose I have 3 projects: A, B, and C. Projects A and B are defined as static library projects in CMake and both A and B have had target_link_libraries() called on them to place dependencies on various boost import libraries. Project C is an executable project and it has had the following called on it:<br>
<br>target_link_libraries( C A B <more boost libraries> )<br><br>Since project C now links against A and B, we need to ensure that the executable generated by building project C is able to find the DLL files required by projects A, B, and C itself. Because of this, I need to be able to "recursively" find all of the import library dependencies for project C (Which if done correctly would provide a list of library dependencies of A and B as well).<br>
<br>Once I have this "flattened" list of dependencies, I replace all the *.LIB extensions with *.DLL (On windows) and copy those DLL files to the location of the executable!<br><br>Because this problem is so complex, I avoided explaining it to begin with to save some trouble.</blockquote>
<div><br>Sorry, I don't have the answer to your question but I thought I'd share the way we solved a similar problem at work in case you can't figure out a way to do it the way you want.<br><br>At work we simply add the DLL files manually to one of several lists. We use one list for MSVC Debug builds, one for MSVC Release builds, and one for MinGW builds. Then at the bottom of our toplevel CMakeLists.txt we call a macro to have these DLL files copied to the build tree. It's not exactly elegant but it gets the job done.<br>
<br>Many of our 3rd party packages use different DLL filenames than their LIB imports which is certainly something to think about when pondering the approach you've outlined above. In the event an external package has a lot of DLLs we have used FILE(GLOB...) in the past so not everything has to be listed explicitly.<br>
<br>We don't have the problem of dealing with dependencies that you have. One approach you could use is to add the logic that selects the DLLs to install alongside ADD_EXECUTABLE() and ADD_LIBRARY(). If target A, B, and C need boost_signals DLL for example you could simply have it add the filename to the global list. Then at the bottom of your main CMakeLists.txt simply perform the copy of all of the files that you need and/or call INSTALL_*(). Duplicate files could simply be excluded by calling LIST(REMOVE_DUPLICATES..)<br>
<br><br></div></div><br>-- <br>Philip Lowman<br>