[vtkusers] Interacting with VTK under Mac OS X

[Mike Jackson]

On Mar 16, 2007, at 12:06 PM, Brad King wrote:

> Martin Costabel wrote:
>> Mike Jackson wrote:
>>> Here is the deal. You have TWO choices. Pick ONE..
>>
>> Unfortunately, both don't make sense when you use a package  
>> manager like
>> MacPorts or Fink or even Xcode. It is a pity that the cmake  
>> developers
>> don't understand this.
>
> We understand it just fine.  CMake 2.4 has full support for rpath and
> install_name with different settings for build tree and install tree.
> It's documented in the SET_TARGET_PROPERTIES command.  A packager can
> get the VTK binaries to install with the desired rpath or install_name
> by setting these variables in the cache with the -D option on the  
> CMake
> command line:
>
> CMAKE_INSTALL_RPATH
> CMAKE_INSTALL_NAME_DIR

Ok, great.. so I tried this in the following way:

$ cmake ../ -D CMAKE_INSTALL_NAME_DIR:STRING=@executable_path/../PlugIns
CMake Error: The source directory "/Users/mjackson/Task_4/Workspace/ 
CTMDCore/Build/PlugIns" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.

and that is the error I get.

Also, I would rather be setting this in the CMakeLists.txt file  
instead of passing it on the command line.

I tried setting these in my CMakeLists.txt file but got no joy from  
that also.

>
>> In linux, it is quite obvious that you have *three* locations, the  
>> build
>> tree, the package build tree where the first provisional installation
>> happens, and the final install location. For any package manager  
>> system,
>> even on MacOSX, the situation is the same. Cmake doesn't understand
>> this, while gnu libtool, for example, has sophisticated and well- 
>> tested
>> methods to implement this on MacOSX.
>
> CMake does support this.  The initial build tree location is
> configurable by EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH.  The
> install tree location is specified with the INSTALL commands.  The
> provisional install location for packaging is set by using DESTDIR
> during install.
>
> The only thing it won't do is setup the rpath or install_name in the
> DESTDIR directory since AFAIK apps do not need to run from it  
> because it
> is meant for creating tarballs or packages.

Not sure I am following here. Is there an example project that we can  
all look at? something simple that creates a Lib and executable and  
then "installs" them into a packaging location along with a header  
file (just to be complete). The install_name on the lib should be the  
eventual install location and NOT the provisional location. I think  
this would help clear everything up.
    From what I am understanding then, I should be able to create a  
library with an "install_name" of @executable_path/../PlugIns/ 
libMyGreatLibrary.dylib.   I am still failing at doing that without  
resorting to hacking in the CMake platform modules. I am running  
cmake 2.4.6. Again, a short example would clear this up for everyone.


>
>> A final remark:
>> We are talking only about install_name here, but the situation is  
>> worse
>> with respect to compatibility_version which the cmake people do  
>> not seem
>> to have heard about, but which is also an important feature of Darwin
>> dylibs.
>
> It's true that this is not currently supported by CMake, but CMake  
> does
> do the soname-based symlink stuff to make sure the proper libraries  
> are
> found.  There is a feature request here for setting the
> compatibility_version:
>
> http://www.cmake.org/Bug/bug.php?op=show&bugid=4383
>
> -Brad


Thanks for the help and looking forward to some examples
Mike Jackson