[CMake] padding link arguments to the linker

[Mike Jackson]

On Feb 8, 2006, at 10:37 AM, Brad King wrote:

> Brad King wrote:
>> The VTK CMake code provides an interface to allow some  
>> customization of the build.  Create a file Common/ 
>> LocalUserOptions.cmake in either the VTK build tree or the source  
>> tree.  Add this line:
>> SET_TARGET_PROPERTIES(vtkCommon PROPERTIES LINK_FLAGS
>>  "-install_name @executable_path/../Plugins/libvtkCommon.dylib")
>
> You might also be interested in this tool:
>
> http://developer.apple.com/documentation/Darwin/Reference/ManPages/ 
> man1/install_name_tool.1.html
>
> -Brad

Yes.. I have used that tool on some other libraries. The problem is  
that the path that is stored in the library must be the same length  
or LONGER than the path you want to change it to. So I did a  
make;make install on VTK. Running otool -L on /usr/local/lib/ 
libvtkCommon.dylib gives:

110:[mjackson at Aeryn:/usr/local/lib]$ otool -L libvtkCommon.dylib
libvtkCommon.dylib:
         libvtkCommon.dylib.5.0 (compatibility version 0.0.0, current  
version 0.0.0)
         libvtksys.dylib.5.0 (compatibility version 0.0.0, current  
version 0.0.0)
         /System/Library/Frameworks/AppKit.framework/Versions/C/ 
AppKit (compatibility version 45.0.0, current version 824.33.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 88.1.2)
         /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,  
current version 7.3.0)
         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
current version 1.0.0)

So here the problem is that I want to replace:
libvtkCommon.dylib.5.0
with
@executable_path/../Plugins/libvtkCommon.dylib

This isn't going to work because I want to replace a shorter path  
with a longer path.

Now, the whole reason I am going down this path is to be able to  
include the dylibs in my app package and not have the user have to  
"install" vtk into /usr/local/lib which may require Admin privileges.  
I would rather give them a single .app package that they can drag and  
drop where ever they choose.

So to have to create a cmake file for each module, while it should  
work, isn't necessarily the most efficient solution. Is there a way  
to work this into cmake itself?

Thanks
Mike Jakckson