[vtkusers] Interacting with VTK under Mac OS X

[Brad King]

Martin Costabel wrote:
> Brad King wrote:
> []
>> The reason it doesn't work in VTK 5.0 is because that was released
>> before CMake 2.4 so it does a big hack to prevent installation with any
>> kind of rpath enabled.  Also the default behavior for the release branch
>> is to have rpaths off. 
> 
> OK, this explains a lot. Is this fixed in more recent branches ov VTK? 
> Do you know if it is fixed in ParaView-2.6.0 (which does not want to 
> build for some other reason)?

VTK from CVS already has the patch I sent you.  I'm pretty sure PV 2.6 
does also.

>> to the source tree.  You may also need to use SET_TARGET_PROPERTIES to
>> tweak the setting for a few targets, but probably not.
> 
> This is something I never understood. Where in the VTK sources would I 
> add SET_TARGET_PROPERTIES, and how?

Anytime after the target is added by ADD_LIBRARY in a CMakeLists.txt 
file you can use SET_TARGET_PROPERTIES.  In VTK though the main targets 
are added by the file VTK/CMake/KitCommonBlock.cmake.  If you look at 
that file you will see that it supports loading per-build or 
per-source-tree user-defined files called LocalUserOptions.cmake.  You 
can put a file with this name in each kit's directory and put the 
SET_TARGET_PROPERTIES in there.  Alternatively you could just hack up 
the KitCommonBlock.cmake file.  Another way is to note this code at the 
bottom of the common file:

IF(VTK_LIBRARY_PROPERTIES)
   SET_TARGET_PROPERTIES(${KIT_LIBRARY_TARGETS} PROPERTIES
     ${VTK_LIBRARY_PROPERTIES}
     )
ENDIF(VTK_LIBRARY_PROPERTIES)

If you set VTK_LIBRARY_PROPERTIES in your cache you can add properties 
to every kit library.  See the top level CMakeLists.txt file for the 
default settings.

> The python modules (things like libvtkIOPython.so) in Wrapping/Python 
> are linked with the VTK dylibs while these still have the wrong 
> install_name, namely the one in the build tree. And since the python 
> modules are installed via setup.py, they don't get the install_name_tool 
> treatment with which cmake changes the wrong install_names to the right 
> ones at installation time. The result is that the installed python 
> modules will not work, because they still have the wrong install_names 
> of the dylibs hardcoded inside.
> 
> What is the trick to activate the install_name_tool stuff also for the 
> python modules? There are 11 of them with a dozen or so install_names to 
> change for each one, so I'd rather not run install_name_tool by hand.

I do not know what the python setup.py way to do that is supposed to be. 
  I used to install the python modules via CMake's install facility but 
python people complained and told me to use setup.py.  One way to work 
around the problem is to set CMAKE_BUILD_WITH_INSTALL_RPATH to true in 
your cache (-DBUILD_WITH_INSTALL_RPATH:BOOL=1 on command line).  This 
will make sure the libraries are all built in the source tree with the 
install_name they will have in the install tree.  That way when the 
python modules link they will get the proper paths.  The cost of this 
workaround is that you will not be able to run anything from the build tree.

Another idea is to set -DCMAKE_SKIP_BUILD_RPATH:BOOL=1 which will cause 
the build-tree versions to have no directory in their install_name 
field.  The python modules will get linked and copy just the library 
name part of the install_name.  When the libraries are installed they 
will get install_name_tool-ed to the proper install-tree install_names. 
  Then the setup.py will install python modules that do not reference 
any particular directory.  Then modify the python part fo the vtk 
package so that it sets DYLD_LIBRARY_PATH properly to the install-tree 
location when importing the c++ part of the modules.  Then you will get 
proper install-tree behavior but still be able to run VTK from the build 
tree by setting DYLD_LIBRARY_PATH properly.

If you get the latter version working I'll be happy to put the necessary 
python wrapper modifications in CVS VTK.

-Brad