[CMake] How not to copy a link

[David Cole]

On Sat, Jan 7, 2012 at 9:47 AM, David Cole <david.cole at kitware.com> wrote:
> On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling <mhertling at 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.

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. 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.


Cheers,
David