[vtk-developers] Add python version to all vtk libs that have python dependency

[Ben Boeckel]

On Tue, Oct 06, 2015 at 15:00:29 -0600, David Gobbi wrote:
> > So…what about modules which *link* to vtkFiltersPython or
> > vtkPythonInterpreter? Which one do you get? It should be the Python that
> > is *currently* found in the finding project, but who knows?
> >
> 
> Only the filename is changed, not the target name.  CMake
> uses target names to deal with dependencies.
> 
> The only real problem is when non-CMake projects try to find
> these libraries.

No, it isn't just a problem there. Say I have a VTK-using project where
I want to use vtkPythonInterpreter. My modules.cmake says:

    vtk_module(vtkFooBar
        PRIVATE_DEPENDS
            vtkPythonInterpreter)

What Python version do I get? How do I tell it that I need Python3.3
support? 2.7 and 3.3? What error message do I get when it mismatches?
How can both module files be installed at once?

> > This will need module logic awareness to duplicate any modules (and
> > tests) which link to a versioned library to build for all versions. The
> > file dropped in the Modules/ directory should also have this suffix so
> > that vtkFiltersPython27 can coexist with vtkFiltersPython34.
> 
> My motivation is to make it possible for the distro folks (e.g.
> debian, arch linux) to build vtk packages... and I agree that
> module awareness of duplicate libraries would be a very nice
> thing (if someone has the time).

Understood, but the library itself is not the only thing which needs
duplicated between the two installs. Looking around a bit:

  - vtkPythonConfigure.h;
  - headers for any Python-using modules[1];
  - Rendering/Matplotlib (uses vtkPythonInterpreter);
  - Parallel/MPI4Py (see below for why this is another big hurdle);
  - Rendering/Tk (not sure if these are version agnostic though);
  - Web/Core (uses Py_* calls); and
  - vtkxdmf2 has some Python code in it.

Note that a similar issue exists for MPI backends; OpenMPI and MPICH
need separate ParaView builds currently. Note that Parallel/MPI4Py is
distinct based on MPI implementation and Python version, so that's 4
variant builds there.

> > I don't think building a single VTK with Python2 and Python3 from one
> > build tree is feasible (nevermind multiple versions of either Python2 or
> > Python3 in the same build).
> 
> What of the distro folks then?  I think we should at least try to meet
> them halfway.

Let's not meet them halfway with a halfway solution. The veneer of
changing just the library name is pretty thin.

--Ben

[1]Arguably, vtkFiltersPython should be only a Python module, not a VTK
module, but vtkPythonInterpreter still exists anyways, so it doesn't
remove these problems.