[vtk-developers] VTK/Python and Sun new discoveries
prabhu at aero.iitm.ernet.in
Fri May 24 13:22:49 EDT 2002
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
(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
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
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.
>>>>> "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
More information about the vtk-developers