[Paraview] ParaView on exotic platforms

Utkarsh Ayachit utkarsh.ayachit at kitware.com
Fri Sep 11 11:45:54 EDT 2009


I think Nikhil forced that name since the mpi4py internals expected
that name (Berk should know the details) for the library. So merely
changing the library name will break mpi4py. May be an easier thing
would be an option to build ParaView wihtout mpi4py. It's not a
critical component of ParaView or paraview-python in any case.

Utkarsh

On Fri, Sep 11, 2009 at 11:42 AM, pat marion <pat.marion at kitware.com> wrote:
> Hi,
>
> As David pointed out, the library for MPIPython is named in a
> non-standard way due to this line:
>
>  SET_PROPERTY(TARGET MPIPython PROPERTY PREFIX "")
>
> Then we have Utilities/mpi4py/mpi4py/MPI.py which contains the single line:
>
>  from MPIPython import *
>
> To conform with all of our other module files, it could be changed to
> look something like this:
>
> import os
> if os.name == "posix":
>    from libMPIPython import *
> else:
>    from MPIPython import *
>
> If there is no great reason to use the name MPIPython.so instead of
> libMPIPython.so, I think we remove the cmake code for the non-standard
> name.  I'll do this later today unless I hear noise...
>
> Pat
>
> On Fri, Sep 11, 2009 at 11:20 AM, Berk Geveci <berk.geveci at kitware.com> wrote:
>> Pat,
>>
>> You probably have the most experience in this. Can you comment?
>>
>> Thanks,
>> -berk
>>
>> On Tue, Sep 8, 2009 at 10:17 PM, David Thompson <dcthomp at sandia.gov> wrote:
>>> Hi all,
>>>
>>> I've been working to get ParaView (with Python turned ON) compiled on an HPC
>>> platform that doesn't support shared libraries. It almost works, but there
>>> is at least one little glitch that I don't see an easy fix for: during CMake
>>> configuration, ParaView creates a file named
>>>  Utilities/VTKPythonWrapping/Executable/pvpythonmodules.h
>>> which defines a routine that initializes all of the python modules ParaView
>>> requires. Unfortunately, this file is written by a macro defined in
>>> FindPythonLibs.cmake which uses a list of the modules and assumes that the
>>> function to initialize each one will be named
>>>        'init' + PREFIX + moduleName + SUFFIX
>>> This doesn't work for the mpi4py module because the build system has
>>> overridden the name of the dynamically-loaded module name. Instead of
>>> libMPIPython.so, it is simply MPIPython.so.
>>>
>>> So far, I've manually edited the pvpythonmodules file but it would be nice
>>> to have a real solution committed. Should I
>>> 1. Un-override the non-standard library name when building static Python
>>> modules
>>> 2. Change PYTHON_ADD_MODULE and PYTHON_WRITE_MODULES_HEADER to keep a list
>>> of target names (and (a) how can I do this when the target name might be
>>> changed later in CMake parsing? (b) will VTK's FindPythonLibs.cmake always
>>> be used or might the version distributed with CMake also need to change?)
>>> 3. Do something else?
>>>
>>>        Thanks,
>>>        David
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the ParaView Wiki at:
>>> http://paraview.org/Wiki/ParaView
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.paraview.org/mailman/listinfo/paraview
>>>
>>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://www.paraview.org/mailman/listinfo/paraview
>


More information about the ParaView mailing list