On Wed, Jan 11, 2012 at 10:10 AM, Michael Hertling <mhertl...@online.de> wrote: > On 01/07/2012 03:52 PM, David Cole wrote: >> On Sat, Jan 7, 2012 at 9:47 AM, David Cole <david.c...@kitware.com> wrote: >>> On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling <mhertl...@online.de> >>> wrote: >>>> On 01/06/2012 07:51 PM, Kevin Burge wrote: >>>>> Thanks David. These are external libraries built outside of CMake, >>>>> without CMake, not imported via any of the import capabilities of cmake, >>>>> and that need to be installed alongside my CMake built files. I think >>>>> I'm just going to do the install with the rename. Requires me to be >>>>> more explicit, but, it's not like it changes all that frequently. >>>> >>>> Isn't it sufficient to copy such SONAME symlinks as they are, along with >>>> the actual library files, of course? Having a symlink from the SONAME to >>>> the library file is a basic mean of the ABI management on platforms with >>>> advanced - ;-) - support of shared libraries. Besides, these symlinks >>>> are automatically created by ldconfig when the latter processes the >>>> directory. >>>> >>>> Anyway, w.r.t. your initial question, I'd usually suggest to use the >>>> GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior >>>> to the INSTALL() command, but it seems to not work as expected: >>>> >>>> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR) >>>> PROJECT(P NONE) >>>> SET(CMAKE_VERBOSE_MAKEFILE ON) >>>> EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E >>>> touch xyz.dat.0) >>>> EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E >>>> create_symlink xyz.dat.0 xyz.dat) >>>> GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH) >>>> MESSAGE("XYZ: ${XYZ}") >>>> >>>> Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH), >>>> >>>> "... the full path with *all* symlinks resolved (REALPATH)." >>>> >>>> I'd expect to see >>>> >>>> XYZ: .../xyz.dat.0 >>>> >>>> instead of >>>> >>>> XYZ: .../xyz.dat >>>> >>>> Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof? >>>> >>>> Regards, >>>> >>>> Michael >>>> >>>>> On 01/06/12 12:45, David Cole wrote: >>>>>> Have you considered setting the VERSION and SOVERSION target >>>>>> properties on your libraries instead of doing the symlinks yourself? >>>>>> CMake will build and install the symlinks automatically for you on >>>>>> platforms where they are supported if you set these target properties. >>>>>> >>>>>> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION >>>>>> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION >>>>>> >>>>>> (Or was that just an example, and you need to do this with other >>>>>> symlink files that are not simply the version symlinks for a >>>>>> library...?) >>>>>> >>>>>> >>>>>> HTH, >>>>>> David >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://www.cmake.org/mailman/listinfo/cmake >>> >>> It works if you use: >>> >>> GET_FILENAME_COMPONENT(XYZ ${CMAKE_CURRENT_BINARY_DIR}/xyz.dat REALPATH) >>> >>> I'm not 100% sure if the behavior is expected to be defined for >>> non-full paths. Hopefully Brad sees this and chimes in. If not, I'll >>> try to remember to ask him about it on Monday. >>> >>> >>> HTH, >>> David >> >> >> It appears to be resolved w.r.t. the current *source* directory when >> you do not give the full path, and since "xyz.dat" does not actually >> exist in the source dir, there's no way we can know that it is >> supposed to be a symlink. >> >> But get_filename_component has to work with non-existing files since >> some people need that simply to compute where files should go, or what >> other file's base names should be based on CMake variables alone... >> >> Hope that explains it better. > > Yes, it does; thanks for straightening this out. Actually, it's rather > obvious that the ABSOLUTE/REALPATH clauses of GET_FILENAME_COMPONENT() > do need a reference point, but perhaps, one should document explicitly > that it's CMAKE_CURRENT_SOURCE_DIR, whereas CMAKE_CURRENT_BINARY_DIR > won't be taken into account. Elsewhere, CMake behaves differently. >
Is it CMAKE_CURRENT_SOURCE_DIR? Or is it the current working directory of the cmake process, which happens to be CMAKE_CURRENT_SOURCE_DIR when you make the call ...? >> I know it's *possible* to use non-full paths in many contexts within >> CMake and still get the results you expect, but because of little >> nuggets like this, ... >> >> ... I always, always, always use full paths anyway, unconditionally. [...] > > With ADD_EXECUTABLE() and ADD_LIBRARY(), too? ;-) But seriously... Yes, even with them. Exception: when I'm editing a CMakeLists file that pre-dates my involvement, and I'm just making an edit to blend in with what's there and working already... And especially with add_custom_command, add_custom_target, execute_process calls. And file DEPENDS clauses for anything. > >> [...] I >> always recommend to everyone that they also adopt this CMake best >> practice of referring to files by their full path names whenever >> possible. It eliminates confusion, ambiguity and unintended mistaken >> results -- and is 100% absolutely worth the effort. > > Definitely agreed, but there're some commands which are typically used > with relative paths, although it's not explicitly documented how they > behave in this respect. Notable examples are the already mentioned > ADD_EXECUTABLE/LIBRARY() or SET_SOURCE_FILES_PROPERTIES() - IMO, the > latter should behave in the same manner as the formers, so one can use > the same source file specifications. Perhaps, one could add a few lines > to the documentation in order to clarify for which commands/properties/ > etc. a relative path does behave well, e.g. like for ADD_SUBDIRECTORY(). > Better documentation is always a good thing. I will not argue against improving the documentation. However: Using full paths always so that you don't have to remember how relative paths are treated differently in different contexts is an even better thing. The simple fact is: if you always use full paths, you never have to think about relative paths, and your CMake code will be better. Because this practice will eliminate a whole slew of possible thinking and documentation lookup mistakes that you can make along the way. > Regards, > > Michael > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake Sincerely, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake