The current dependency relationship in vtk is unclear and misleading.
This MR tries to rewrite them based on header files inclusion of headers
and source files in each module. Corner cases are considered and
modules are sorted in alphabetical order to facilitate future reference.
See details in my gitlab python based script project. In future we can continue
using this script to clean the VTK Dependency easily from
time to time.

One of the VTK dashboards had problems evaluating PYTHON_VERSION,
so stick with PYTHON_MAJOR_VERSION and PYTHON_MINOR_VERSION instead.
Also, change SEND_ERROR to FATAL_ERROR.

We will be removing support for Python 2.6 and Python 3.2 in the near
future, so add deprecation warnings for these.  For older versions of
Python, generate an error.  This deprecation is due in part to the
fact that WebPython now requires Python 2.7 or 3.3+.

vtk(.*)\(const vtk\1&\);\s*//\s*Not implemented[\.]*
to
vtk\1(const vtk\1\&) VTK_DELETE_FUNCTION;

vtk(.*)\(const vtk\1 &\);\s*//\s*Not implemented[\.]*
to
vtk\1(const vtk\1 \&) VTK_DELETE_FUNCTION;

vtk(.*)\( const vtk\1 & \);\s*//\s*Not implemented[\.]*
to
vtk\1( const vtk\1 \& ) VTK_DELETE_FUNCTION;

vtk(.*)\( const vtk\1& \);\s*//\s*Not implemented[\.]*
to
vtk\1( const vtk\1\& ) VTK_DELETE_FUNCTION;

vtk(.*) \(const vtk\1&\);\s*//\s*Not implemented[\.]*
to
vtk\1 (const vtk\1\&) VTK_DELETE_FUNCTION;

(operator\s*=.*);\s*//\s*Not\s*implemented[\.]*
to
\1 VTK_DELETE_FUNCTION;

After that, this finds basically nothing:

operator.*implemented

then manually reverted changed files in VPIC and KWSys folders.

These files will eventually need vtkConfigure.h
for eventual VTK_DELETE_FUNCTION usage.

Code extracted from:

    https://gitlab.kitware.com/third-party/proj.git

at commit 41bdf05361007f8c5186f3df9944d86bb273ed13 (for/vtk).

This resolves linking errors when doing static cross-compile builds
against python with no thread support.

Some python calls take care of realeasing gil (eg. Py_Finalize), some when using gilEnsurer before this call, it is needed to only Ensure gil without releasing when going out of scope, has it has already been released. If not python will output a warning.
So a noRelease parameter have been added to gilEnsurer and this parameter have been used where it was necessary.

1. Defining a gilEnsurer class to use as RAII for gil
2. Ensuring critical calls to python, where they could be concurrency, only when a cmake option is defined
3. Correcting the access to python in vtkPythonInterpreter::Initialize
4. Forcing the use of gil in the Interactive Python Interepreter for auto completion http://www.vtk.org/Bug/view.php?id=15699
5. Forcing the use of gil for prependPythonPath : http://www.vtk.org/Bug/view.php?id=15698

The Python pyport.h header defines macros for toupper and other
ctype functions when compiled with __APPLE__ defined.  These macro
definitions are problematic for C++ in general, and cause compile
errors with modern compilers.

This is no longer needed, and is needlessly restrictive.
It's best to have a header that can be used by multiple
versions of python.

When built with certain versions of Python, a VTK build with
VTK_WRAP_PYTHON enabled results in many build warnings. For example:

Python 2.7.10:

    c:\python27\include\pyconfig.h(444): warning C4005: 'HAVE_ROUND' : macro redefinition
              C:\dev\VTK\Utilities\Python\vtkPython.h(77) : see previous definition of 'HAVE_ROUND'

This warning occurs because both vtkPython.h and Python.h define the
HAVE_ROUND macro, but the definitions don't match. Python 2.7.9+ and
Python 3.4.2+ define HAVE_ROUND when compiling with Visual Studio 2013+
(see http://bugs.python.org/issue21958).

Python 3.4.1:

    c:\python34\include\pymath.h(22): warning C4273: 'round' : inconsistent dll linkage
              C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(516) : see previous definition of 'round'
    C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xtgmath.h(206): warning C4273: 'round' : inconsistent dll linkage
              C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(516) : see previous definition of 'round'

This warning occurs because neither Python.h nor vtkPython.h define HAVE_ROUND.

This commit removes the build warnings by:
- changing the HAVE_ROUND macro definition to match Python's definition
- removing the Python version check

When built with certain versions of Python, a VTK build with
VTK_WRAP_PYTHON enabled results in many build warnings. For example:

Python 2.7.10:

    c:\python27\include\pyconfig.h(444): warning C4005: 'HAVE_ROUND' : macro redefinition
              C:\dev\VTK\Utilities\Python\vtkPython.h(77) : see previous definition of 'HAVE_ROUND'

This warning occurs because both vtkPython.h and Python.h define the
HAVE_ROUND macro, but the definitions don't match. Python 2.7.9+ and
Python 3.4.2+ define HAVE_ROUND when compiling with Visual Studio 2013+
(see http://bugs.python.org/issue21958).

Python 3.4.1:

    c:\python34\include\pymath.h(22): warning C4273: 'round' : inconsistent dll linkage
              C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(516) : see previous definition of 'round'
    C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xtgmath.h(206): warning C4273: 'round' : inconsistent dll linkage
              C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(516) : see previous definition of 'round'

This warning occurs because neither Python.h nor vtkPython.h define HAVE_ROUND.

This commit removes the build warnings by:
- changing the HAVE_ROUND macro definition to match Python's definition
- removing the Python version check

This is a large change that adds conditional compilation to support
both python 2 and python 3.  The header vtkPythonCompatibility.h
does a lot of the necessary work:
1) PyInt is redefined to PyLong for py3k
2) PyString is redefied to PyUnicode for py3k
3) PyBytes is redefined to PyString for python 2

aka MSVC++ 8.0 / Visual Studio 2005.

VTK now requires MSVC++ 9.0 / Visual Studio 2008.

New MSVC has it while Python binaries are built with MSVC 2008.

Used the following command:

find . \( -iname *.h -and -type f \) -exec perl -pi -w -e 's/__vtk(.*)_h/vtk$1_h/g;' {} \;

Fixes many, but not all, clang -Wreserved-id-macro warnings.

Change-Id: I694ff053cb204c70e37b261296f496064d91fc07

Used the following command:

find . \( -iname *.in -and -type f \) -exec perl -pi -w -e 's/__vtk(.*)_h/vtk$1_h/g;' {} \;

Fixes many, but not all, clang -Wreserved-id-macro warnings.

Change-Id: I86db91ad530c203347f2b0dfd29c31f843c3f2b7

Change-Id: Iad8a7d033b74e558b6a4e9692fdf851bf711c637

This property allow ParaView to override the default VTK
value ($BUILD/Wrapping/Python/) to be where ParaView
expect its Python modules to be build.

Change-Id: I5c2cc016356d7a4320f9f5c999225835abcd6bb1

Advanced cache variable VTK_INSTALL_PYTHON_MODULE_DIR now controls
where the install target puts the python .py files and corresponding
python extension libraries (*Python.so or *Python.dll). ThirdParty
modules like Zope, Twisted and Autobahn should be placed there,
vtk extensions should go inside the vtk directory there.

System installers for instance will likely want to set it to be:
/usr/local/lib/pythonX.Y/site-packages #Linux
/Library/Python/X.Y/site-packages #Mac
C:/PythonXY/Lib/site-packages #Windows

ParaView will use it to put the VTK python modules underneath its own.
Also for ParaView's use, there is once again a way to disable installation
of the vtkpython binary. Now it is done by setting VTK_INSTALL_NO_PYTHON_EXES.

The change also updates the README.txt per VTK 6.X layout and
removes references to setup.py, which we no longer support.

Change-Id: I92c1d65c8ca8aa44ca2d54cc4526bbc72f42eb0d

for use by other vtk modules that make and install python modules

Change-Id: Ia043b89c540df6de6af713c7c634833ab4b1d718

Python.h defines hypot to be _hypot, which can cause a level 4
warning coming from math.h with the Visual Studio compiler.
Use pragma warning to make sure that only level 1 warnings
may be emitted during the include of Python.h.

Also, remove the custom expression that was trying to suppress
this warning since it had a missing space in it that prevented
the match anyhow. It's now unnecessary since the warning is
not emitted.

Change-Id: Iaf77a0ae76ebab5056fb02d3895e2084168ad731

The dependency of Rendering/Matplotlib on Wrapping/Python was causing
the latter module to be configured too early.  Wrapping/Python must
be configured after all wrapped modules or it will not be able to capture
all of the wrapped modules properly.

The solution is to create a new Python vtk-module that both Wrapping/Python
and Rendering/Matplotlib can depend on.

Change-Id: I8348fd80147126866dec91488cb0771a7f412636