[Paraview-developers] static build and shared library plugins

Utkarsh Ayachit utkarsh.ayachit at kitware.com
Fri Jun 13 07:50:04 EDT 2014


Burlen,

Ben recently pushed changes to ParaView git/master to support the
behavior I mentioned either in this thread -- in static builds,
plugins are now linked in, but not loaded until user "loads" them from
"Manage Plugins" dialog. Feel free give it a try and let us know if
you spot any issues or have suggestions.

Thanks
Utkarsh

On Thu, Apr 17, 2014 at 8:47 AM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> I suppose so, esp since it's becoming  a hassle for HPC/Catalyst. I
> marked it for 4.2. http://paraview.org/Bug/view.php?id=14542
>
> On Wed, Apr 16, 2014 at 6:45 PM, Burlen Loring <burlen.loring at gmail.com> wrote:
>> Sounds even better. Is this an item that you will tackle before the next
>> release?
>>
>>
>> On 04/16/2014 12:57 PM, Utkarsh Ayachit wrote:
>>
>> Burlen,
>>
>> A solution for this has been on my todo list for a long time. We
>> really don't need to go as far a building shared libraries for plugins
>> even with BUILD_SHARED_LIBS=OFF ( I am not sure that'd work, but we
>> can punt on that). We can continue do exactly what happens now as far
>> as the build goes. The only thing that needs to change is that
>> currently we "import" the plugin during initialization. That
>> "importing" needs to happen on demand rather than on startup. To
>> clarify, I am attaching how the "init" code looks like for static
>> builds. As you can see, PV_PLUGIN_IMPORT_INIT(..) can happen. The only
>> thing we need to delay is PV_PLUGIN_IMPORT(). That should happen when
>> the client requests it. Plugins don't do anything until that import
>> call, and hence will not have any effect on the application until that
>> import call.
>>
>> The painful part is updating the plugin logic UI etc to ensure that it
>> shows up even when BUILD_SHARED_LIBS is off. The disable "Load" when
>> BUILD_SHARED_LIBS=OFF so only compiled in plugins are shown.
>>
>> Thoughts?
>>
>> Utkarsh
>>
>>
>>
>> On Wed, Apr 16, 2014 at 3:42 PM, David E DeMarle
>> <dave.demarle at kitware.com> wrote:
>>
>> Sounds great - as long as one side of the option keeps the enabled plugins
>> baked in the way they are now for those few remaining and exceedingly lame,
>> platforms that have no support for dynamic loading at all.
>>
>> David E DeMarle
>> Kitware, Inc.
>> R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909
>>
>>
>> On Wed, Apr 16, 2014 at 3:33 PM, Andy Bauer <andy.bauer at kitware.com> wrote:
>>
>> I'm in favor of this. The streaming particles plugin is the latest to
>> cause me some grief for cross-compiled static builds on a Cray with the
>> exact behavior you mentioned (crashing at the first render).
>>
>>
>> On Wed, Apr 16, 2014 at 3:29 PM, Burlen Loring <burlen.loring at gmail.com>
>> wrote:
>>
>> Hi All,
>>
>> How would you feel about a build option that will allow normal shared
>> library based, run time loaded, plugins when PV is built with
>> BUILD_SHARED_LIBS=OFF?
>>
>> The reason I'm interested is that static link handling of plugins are
>> currently the remaining obstacle to deploying static library based PV at
>> NERSC. We need the static library build for performance reasons at the same
>> time various users have request plugins. Recent versions of VTK supported
>> python and static library build, yay! plugins are the remaining issue.
>>
>> Burlen
>>
>> for context here's a recap of static build plugin issues, when the
>> plugins are baked into the server:
>>
>> 1) upon job startup users are confronted with a complicated pop up dialog
>> through which they must then load all of the missing plugins, else PV
>> crashes on the first render.
>>
>> 2) some of the plugins change the GUI when loaded
>>
>> both are confusing for many users
>>
>> _______________________________________________
>> Paraview-developers mailing list
>> Paraview-developers at paraview.org
>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>
>>
>> _______________________________________________
>> Paraview-developers mailing list
>> Paraview-developers at paraview.org
>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>
>>
>> _______________________________________________
>> Paraview-developers mailing list
>> Paraview-developers at paraview.org
>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>
>>
>>
>> _______________________________________________
>> Paraview-developers mailing list
>> Paraview-developers at paraview.org
>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>
>>
>>
>> _______________________________________________
>> Paraview-developers mailing list
>> Paraview-developers at paraview.org
>> http://public.kitware.com/mailman/listinfo/paraview-developers
>>


More information about the Paraview-developers mailing list