[vtkusers] [Python] Two Init-level class wrappers

[Eric Boix]

	Dear Vtk.4.x + Python users,

	As I understand it, building the Python wrapers of some VTK custom
classes is a two stage process:
  1/ invoke vtkWrapPython on each of the vtk classes include files (as many
    invocations as they classes).
  2/ generate the initialisation function of the dynamic library i.e. the
     function that is called by Python when importing, and that shall
     populate the dictionnary with new avalaible classes.

There seems to be two different versions of the code taking care of this
second stage:
 * the first one comes with VTK is located in VTK/Wrapping/vtkWrapPythonInit.c.
   This was the code used by vtk.3.2.
 * the second one, suprisingly enough, comes with CMake as you can find it in 
   CMake/Source/cmVTKWrapPythonCommand.cxx (see the function
   cmVTKWrapPythonCommand::FinalPass). As I understand it, this is the
   way of doing it in vtk.4.x, meaning CMake does the job (I wouldn't dare
   discussing the opportunity of putting some VTK related code within CMake.
   I believe this code is generic enough and the remaining VTK reference
   in the labels/names are only due to history).

Now, if ones looks at the nice frameset for wrapping custom classes that
VTK.4.x provides (see VTK/Examples/Build/vtkMy thanks to Sebastien Barre),
it uses CMake to build the Python library header.

My question is: how long will this duplication of the second stage wrapper
code remain ? Can one hope that the simple version that comes with VTK
(in vtkWrapPythonInit.c) will continue to evolve with Python ? Can I
rely on this vtkWrapPythonInit.c code to maintain my own Makefiles ?
[I know, I know I should move to CMake, but I have so many custom classes
 that I wrap with Makefiles...].

	AtDhVaAnNkCsE,
	Yours,
	Eric Boix.