[vtk-developers] VTK_ENABLE_KITS and VTK_ENABLE_VTKPYTHON

[Ben Boeckel]

Hi,

On Thu, Jul 17, 2014 at 09:54:51 +1000, Andrew Maclean wrote:
> What are these options and what do they do? They have appeared in the recent
> master.

These are meant for ParaView, in two different use cases, explained
below.

> To amplify:
> 1) I am wondering why KITS are being brought back and how linking will work. In
> the case of the usual modular VTK you can, in your CMakeLists.txt file, specify
> a minimal set of libraries. Will this change if KITS are used? If it does, I
> see more problems in supporting the two different versions of VTK i.e VTK and
> VTK with kits, in the CMakeLists.txt files.

This is meant to help reduce the number of shared libraries built with
ParaView. The problem is that on OS X 10.9 has too large of a library
loader path (it used to be a dynamic buffer in the loader, but is now of
a static size). This is triggered by either linking too many libraries
or the paths to the libraries being too long. Due to the variables
available with modular VTK, there should be no difference between the
two (either linking directly to the target or using
${vtk-module}_LIBRARIES). It also requires CMake 3.0 for INTERFACE
libraries so that target linking works transparently.

It is meant to be a purely internal thing and isn't necessary in the
normal course of using VTK.

> 2) Why is there a need to specify that vtkpython and pvtkpython be built? I
> would have thought that once Python is selected that these are built as a
> matter of course.

This is because, in ParaView, we are looking to build a purely static
build with Python and NumPy support. This brings in extra requirements
when linking of Python which (p)vtkpython would need to link (e.g., ssl,
crypto, util, and some others). The solution was to either turn off
vtkpython in this case or to add a magic variable which ParaView sets
for extra libraries (p)vtkpython needs to link to work properly. It was
decided that for ParaView, turning off vtkpython makes the most sense
since pvpython and pvbatch exist.

> Also I see some work is being done to support Python 3. Will there be an option
> to select which version of Python to use?

I hope so (I'm just watching the branch for now).

> As for the tests, I think most of the tests should run in Python 3 the only
> tests I can think that wont are those with a print statement and this is easily
> fixed for both Python 2.6+/3.

Anything that catches exceptions will likely need updated as well (and
the minimum version bumped as there isn't a nice way to catch an
exception that isn't a syntax error in either 2.4 or 3.0 without just
catching a type and asking sys.exc_info() for the actual object). Other
than that, I think we just need to watch for integer division now being
floating point in Python 3.

--Ben