[vtk-developers] Fixing VTK Python Installation

[Prabhu Ramachandran]

>>>>> "Brad" == Brad King <brad.king at kitware.com> writes:

    Brad> Prabhu Ramachandran wrote:
    >> I just checked in the changes for this and am getting dllexport
    >> related errors on the Win32 VC builds.
    >>
    >> http://www.vtk.org/Testing/Sites/dash13.kitware/Win32-vs60/20050813-0300-Nightly/BuildWarning.html

    Brad> The problem is that VTK_PYTHON_EXPORT is coded to export
    Brad> symbols from a library called "vtkCommonPython" but now it
    Brad> needs to export from "vtkCommonPythonD".  I've committed a
    Brad> fix.

OK, thanks for the fix!

    Brad> Do you know why the suffix "D" was chosen?  It makes it look
    Brad> like a debug library.  Should we switch to calling the
    Brad> shared libraries "vtk*Python" and the loadable modules
    Brad> "vtk*PythonM"?  The actual names of the python modules are
    Brad> not really public...they are used only inside the vtk *.py
    Brad> code that loads them.

I really don't know why 'D' was chosen at all.  vtk*Python and
vtk*PythonM sounds OK to me.  The only thing is long time VTK users
would remember that once upon a time, there was only vtk*Python and
these were imported directly (from libvtkCommonPython import *).  So
they might get a little confused.  What do the others think?

    Brad> Also, these errors:

    Brad> http://www.vtk.org/Testing/Sites/destiny.kitware/HP-UX-aCC/20050813-0300-Nightly/BuildError.html

    Brad> are because vtkCommonPythonD is trying to link to the python
    Brad> library, which is static on that machine.  Previously the
    Brad> VTK python shared libraries only linked to the python
    Brad> library on windows.  Was this a bug?

I don't think so.  AFAICT, we did not need to link extension modules
to libpython under Linux or Unix and that looked like a win32
requirement.

    Brad> On UNIX the symbols could be found because the executable
    Brad> that loaded the libraries was linked to the python library
    Brad> and set to export its symbols for use by loaded libraries.
    Brad> I'm not sure this was completely correct but it seemed to
    Brad> work.  I'm attempting to install a shared build of python to
    Brad> solve the problem but we should still resolve this issue.

I see that you have checked in a fix for this.  Thanks!


cheers,
prabhu