Philip Lowman wrote: > On Fri, Dec 12, 2008 at 9:34 AM, Martin Apel <[email protected] > <mailto:[email protected]>> wrote: > > Philip Lowman wrote: > > On Wed, Dec 10, 2008 at 4:04 AM, Martin Apel > <[email protected] <mailto:[email protected]> > > <mailto:[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. Hi Philip,
to me it looks more like a bug, because the documentation for GET_FILENAME_COMPONENT states, that for ABSOLUTE the file name is returned without symlinks. Anyway at least under Unix I could use readlink, but then I will have to do platform-dependant stuff here, which I tried to avoid. Regards, Martin ____________ Virus checked by G DATA AntiVirus Version: AVF 19.219 from 12.01.2009 _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
