[vtk-developers] VTK/Python and Sun new discoveries

[Prabhu Ramachandran]

Hi all,

I have several questions here.  Before anything else, I'd like to
confess my ignorance of any platform apart from Linux (and a wee bit
of Win32 (wee bit tending to zero)).  I simply dont have much
experience with other platforms.  I can obtain access to the other
platforms but I have way too many other things to do.  Consequently I
am not familiar with the various issues with these platforms.  As far
as your reports go I think these are the problems with VTK-Python on
these platforms.  Please correct me if I am wrong.

  (1) (C)Python is implemented in C so most Python installs have a
  Python interpreter thats built using the local C compiler.  VTK uses
  C++ and creates libraries using the C++ compiler.  Apparently,
  non-gcc Python interpreters have trouble importing these
  libraries/modules built by the c++ compiler.  This is clearly a
  vague description but from what I can tell describes the problem
  somewhat?

  (2) The problem seems to occur only with the vtkTkRenderWidget
  related code.  I suspect that the other GUI toolkits do not have the
  same problems because I know that Dave Reed uses vtk-python on a Sun
  with pyGTK.  Can others comment on this?  Andy's reports that the
  Python tests pass without the Tk stuff is also indicative of this.
  For instance do vtkRenderWindowInteractor and friends work fine
  under Sun/SGI?

Assuming that (2) is correct.  The problem somehow seems to be related
Python + Tkinter + vtkTkRender*.  So, could the problem actually be
related to Tcl (since Tkinter uses Tcl underneath)?  I am just
hypothesizing so bear with me.  If Python is able to load the c++
libraries just fine (which is why the tests pass) why does it fail
just when the vtkTk stuff is used?  Is it a problem with the way
tkinter is built? If its a Tkinter problem cant that be fixed in some
other way?  Or is there simply no way to use VTK + Tkinter under
non-gcc platforms without using a specially compiled python
interpreter?

Basically, where is the problem? Python? Tcl? Tkinter? VTK? compilers?
or some combination of all these?

Why am I opposed to having a new interpreter?  Well, it seems
un-Pythonic somehow.  How about cross platform compatibility of code?
Instead of running python test.py you'd run vtkpython test.py.  That
isn't too bad but what else do we loose/gain?  Do we want to make it
load libvtkCommonPython automatically?  Afterall, if you want it to
look and hiss just like python why dont we just let the user import
the modules that they want?  This way we make our lives easier and
things still work just fine.

I have no idea about the ITK problems with static builds.  IIRC static
builds used to work with VTK 3.x.  Was it because of the vtkpython.so
single module approach?  If so, why have we moved away from this
approach for VTK 4.x?  I thought shared libraries were a good idea, so
whats the deal with ITK?

I'm hesitant getting myself involved in any more work because like
David I have a PhD to finish.

cheers,
prabhu

>>>>> "DG" == David Gobbi <dgobbi at irus.rri.ca> writes:

    DG> Andy, Prabhu, I agree that including a vtkpython binary (I
    DG> much prefer calling it 'vtkpython' rather than 'vtkPython') is
    DG> a good idea.  It is trivial to do and it solves a lot of
    DG> problems.  For the SGI I have to re-link the python executable
    DG> with the C++ compiler to make it work, I'm not terribly
    DG> surprised that it is the same under Solaris.

    DG> Perhaps the 'vtkpython' executable could also automatically
    DG> load libvtkCommonPython et al as well?

    DG> And when VTK/python is built, both VTK and python should
    DG> definitely be built shared.  Otherwise it is guaranteed that
    DG> the vtkTkRenderWidget will not work, since when static linking
    DG> is used both VTK and Python will each have their own copy of
    DG> the Tk code and the Tk/Tcl global variables.

    DG> There are ways of building VTK/python static, for example by
    DG> linking the vtkTkRenderWidget.so against the _tkinter.so
    DG> module that comes with python instead of linking it against
    DG> libtk.so.  But unless someone wants to work through all the
    DG> details, add them to the cmake files, and maintain them it is
    DG> better just to tell everyone to build shared.  This is going
    DG> to be a problem with python and ITK, since there is no
    DG> 'shared' option with ITK.

    DG> Prabhu is correct that I am busy right now, I'm reading the
    DG> list and recompiling VTK every so often to make sure that all
    DG> my stuff works with the cvs version of VTK, but I probably
    DG> won't be committing much of anything in the next few months.

    DG>  - David