[Paraview-developers] static build and shared library plugins

[Utkarsh Ayachit]

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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pvStaticPluginsInit.h
Type: text/x-chdr
Size: 1487 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20140416/063ce974/attachment-0001.h>