On Fri, Dec 12, 2008 at 9:34 AM, Martin Apel <span dir="ltr"><<a href="mailto:martin.apel@simpack.de">martin.apel@simpack.de</a>></span> wrote:<br><div class="gmail_quote"><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">Philip Lowman wrote:<br>
> On Wed, Dec 10, 2008 at 4:04 AM, Martin Apel <<a href="mailto:martin.apel@simpack.de">martin.apel@simpack.de</a><br>
</div><div><div></div><div class="Wj3C7c">> <mailto:<a href="mailto:martin.apel@simpack.de">martin.apel@simpack.de</a>>> wrote:<br>
><br>
> Hi there,<br>
><br>
> I am trying to install the boost libraries my software needs into the<br>
> target installation directory as follows:<br>
><br>
> Find_Package(Boost 1.34.1 COMPONENTS filesystem system signals<br>
> program_options REQUIRED)<br>
> FOREACH (Lib ${Boost_FILESYSTEM_LIBRARY} ${Boost_SYSTEM_LIBRARY}<br>
> ${Boost_SIGNALS_LIBRARY} ${Boost_PROGRAM_OPTIONS_LIBRARY})<br>
> INSTALL(PROGRAMS ${Lib} DESTINATION run/bin)<br>
> ENDFOREACH (Lib ${Boost_FILESYSTEM_LIBRARY} ${Boost_SYSTEM_LIBRARY}<br>
> ${Boost_SIGNALS_LIBRARY} ${Boost_PROGRAM_OPTIONS_LIBRARY})<br>
><br>
> The variables returned from FindBoost contain symlinks to the real<br>
> libraries, e.g.<br>
> libboost_system-gcc43-mt-1_35.so -><br>
> libboost_system-gcc43-mt-1_35.so.1.35.0<br>
><br>
> When installing these the files in the destination directory are<br>
> symlinks again, which is not what I want. I tried using<br>
> GET_FILENAME_COMPONENT(LibWithoutSymLink ${Lib} ABSOLUTE)<br>
> in the above loop, but this does not help, the returned path still<br>
> does<br>
> not contain the resolved name. This looks to me like a bug in the<br>
> implementation<br>
> of GET_FILENAME_COMPONENT. Is there any recommended way to install<br>
> referenced libraries including resolving any symlinks?<br>
><br>
><br>
> You could file a feature request to have that implemented. Ultimately<br>
> though that won't be portable because on Windows it would resolve to a<br>
> ".lib" when you would want a ".dll". And you probably want something<br>
> that works now for this.<br>
><br>
><br>
> Boost_INCLUDE_DIR in conjuction with FILE(GLOB...) and INSTALL() would<br>
> probably work much better for you. Perhaps something like this?<br>
><br>
> FILE(GLOB my_boost_system_libs<br>
> ${Boost_INCLUDE_DIR}/lib/libboost_system*.so)<br>
> IF(my_boost_system_libs)<br>
> INSTALL(FILES ${my_boost_system_libs} DESTINATION lib)<br>
> ENDIF()<br>
><br>
> Obviously you would need two GLOB's for this to be portable to WIN32.<br>
</div></div>Hi Philip,<br>
<br>
I tried to avoid this, because the naming scheme for Boost libraries is<br>
complicated (compiler version, threading). Therefore I used the<br>
variables provided by FindBoost to get the names. Anyway I would have<br>
expected GET_FILENAME_COMPONENT to return the referenced file, which it<br>
doesn't. I'm still not sure, if this is a bug or expected behaviour?</blockquote><div><br>This looks like a missing feature request and not a bug. I would request an option be added to GET_FILENAME_COMPONENT that follows symbolic links recursively back to their source (CANONICALIZE perhaps?). In the meantime you can use the "readlink" program to do this for you.<br>
</div></div><br>-- <br>Philip Lowman<br>