[vtk-developers] VTK_ENABLE_KITS and VTK_ENABLE_VTKPYTHON

David E DeMarle dave.demarle at kitware.com
Thu Jul 17 21:40:58 EDT 2014


FYI http://markmail.org/thread/6fybkjbz5xpr3qt7
Is the email thread from the last time we talked about the VTK's minimum
python version.


David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909


On Thu, Jul 17, 2014 at 7:16 PM, Andrew Maclean <andrew.amaclean at gmail.com>
wrote:

> 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
>
> ___________________________________________
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140717/280d7240/attachment-0002.html>


More information about the vtk-developers mailing list