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