[vtk-developers] VTK_ENABLE_KITS and VTK_ENABLE_VTKPYTHON

Andrew Maclean andrew.amaclean at gmail.com
Thu Jul 17 19:16:17 EDT 2014


Thanks for the update Ben.

I didn't realise that this was triggered by OSX10.9

Let me know what I can do in the way of reconfiguring the python tests so
that they run on both Python 3.x and Python 2.6+. I'm happy to spend time
doing this.

I think you are going to have to ultimately bump up the Python version
especially if we want to support Python 3. Currently I think it is 2.5 so
going to 2.6 would be Ok or even 2.7!!!

I remember trying to make Python code run on earlier versions by testing
for the Python version, unfortunately the python interpreter seems to
precompile all branches so this approach failed. I never found a solution.
So this is another argument for bumping the version

I see numpy supports 2.6/7 and 3.x (http://www.scipy.org/scipylib/faq.html).
So I suspect those using ParaView/VTK/Numpy are already using Python
2.6/2.7.

It might be an idea to put it out to the community to see who is actually
using Python 2.5 or earlier with VTK 6.0 and if so would they see any
problems upgrading to Python 2.7.

We really should be supporting Python 3.x because that is where all the
Python development is going on now and I suspect that Numpy and SciPy will
be focussing their efforts there too.

Regards
Andrew


On Thu, Jul 17, 2014 at 11:39 PM, Ben Boeckel <ben.boeckel at kitware.com>
wrote:

> Hi,
>
> On Thu, Jul 17, 2014 at 09:54:51 +1000, Andrew Maclean wrote:
> > What are these options and what do they do? They have appeared in the
> recent
> > master.
>
> These are meant for ParaView, in two different use cases, explained
> below.
>
> > To amplify:
> > 1) I am wondering why KITS are being brought back and how linking will
> work. In
> > the case of the usual modular VTK you can, in your CMakeLists.txt file,
> specify
> > a minimal set of libraries. Will this change if KITS are used? If it
> does, I
> > see more problems in supporting the two different versions of VTK i.e
> VTK and
> > VTK with kits, in the CMakeLists.txt files.
>
> This is meant to help reduce the number of shared libraries built with
> ParaView. The problem is that on OS X 10.9 has too large of a library
> loader path (it used to be a dynamic buffer in the loader, but is now of
> a static size). This is triggered by either linking too many libraries
> or the paths to the libraries being too long. Due to the variables
> available with modular VTK, there should be no difference between the
> two (either linking directly to the target or using
> ${vtk-module}_LIBRARIES). It also requires CMake 3.0 for INTERFACE
> libraries so that target linking works transparently.
>
> It is meant to be a purely internal thing and isn't necessary in the
> normal course of using VTK.
>
> > 2) Why is there a need to specify that vtkpython and pvtkpython be
> built? I
> > would have thought that once Python is selected that these are built as a
> > matter of course.
>
> This is because, in ParaView, we are looking to build a purely static
> build with Python and NumPy support. This brings in extra requirements
> when linking of Python which (p)vtkpython would need to link (e.g., ssl,
> crypto, util, and some others). The solution was to either turn off
> vtkpython in this case or to add a magic variable which ParaView sets
> for extra libraries (p)vtkpython needs to link to work properly. It was
> decided that for ParaView, turning off vtkpython makes the most sense
> since pvpython and pvbatch exist.
>
> > Also I see some work is being done to support Python 3. Will there be an
> option
> > to select which version of Python to use?
>
> I hope so (I'm just watching the branch for now).
>
> > As for the tests, I think most of the tests should run in Python 3 the
> only
> > tests I can think that wont are those with a print statement and this is
> easily
> > fixed for both Python 2.6+/3.
>
> Anything that catches exceptions will likely need updated as well (and
> the minimum version bumped as there isn't a nice way to catch an
> exception that isn't a syntax error in either 2.4 or 3.0 without just
> catching a type and asking sys.exc_info() for the actual object). Other
> than that, I think we just need to watch for integer division now being
> floating point in Python 3.
>
> --Ben
>



-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140718/765bcefd/attachment-0002.html>


More information about the vtk-developers mailing list