[Paraview] Add support for PARAVIEW_EXTRA_EXTERNAL_PLUGINS?

Jacques Papper jacques.papper at gmail.com
Wed Jan 14 12:15:39 EST 2009


John,

I think this would be a very good idea.

So if I put
PARAVIEW_EXTRA_EXTERNAL_PLUGINS : vtkCSCSFluent
then it will prompt for a path and I just give it the path to the source for
example : vtkCSCS/vtkFluentvtkCSCS/
I assume that it will then use the cmake file that's in
vtkCSCS/vtkFluent/pv3-plugin ?

So am I right to assume that in order to use the same methodology with my
plugins I should put a cmake file in a directory called pv3-plugin ?

Regards,
Jacques

2009/1/14 John Biddiscombe <biddisco at cscs.ch>

> Mike
>
>> what is the difference between setting my Module as a
>> PARAVIEW_EXTRA_EXTERNAL_MODULES vs PARAVIEW_EXTRA_EXTERNAL_PLUGINS?
>>
>
> EXTERNAL_MODULES : the source files are added to the target for pvfilters.
> They might be static or dynamic, depending on how your build is configured.
> The code is compiled into pvfilters, the core of paraview.
> CMake picks up the file 'NAME'ParaViewImport.cmake and uses it for the
> sources
>
> EXTERNAL_PLUGINS : when BUILD_SHARED_LIBS is ON the source directory for
> each plugin is supplied and the MACRO "add_paraview_plugin" is called for
> each plugin listed passing the source directory in. The CmakeLists.txt file
> in the directory is used, just as if you were compiling the plugin
> separately. The plugin is added as a separate target to the paraview build,
> and appears just like all those overview/prism plugins that are gradually
> appearing in the build.
>
> I develop custom plugins for several institutions (each one has different
> plugins), and each time I compile paraview for them, I then compile the
> plugins they need afterwards. Each time, they ask, "why can't you just
> compile the plugins at the same time as paraview". Well now I can. I could
> have used the EXTERNAL_MODULES feature as well, but as you have seen from
> emails on this list, there are Fluent, netCDF, OpenDX, blah vlah blah
> modules out there and many other people weant to use them too and expect to
> be able to compile the as plugins, not as internal modules. Plugins are in
> general easier to manage and I don't want to maintain multiple cmakelists
> files
>
> Currently I have 3 setf for each module, and maintaining them is a pain.
> 1) compile as a vtk filter, (use cmakelists.txt)
> 2) compile as a plugin (use pv3-plugin/cmakelists.txt)
> 3) compiles as external_module into paraview (use
> 'NAME'ParaViewImport.cmake)
>
> too much work.
> 3) is no longer required by me.
> 2) is nice because changing a plugin is a quicker make than changing
> paraview source
> 2) also allows me to use my new external_plugins to compile at pv-compile
> time just like I used to with 3)
>
> I hope this thread is finished now.
>
>
> JB
>
>
>
>
> _______________________________________________
> ParaView mailing list
> ParaView at paraview.org
> http://www.paraview.org/mailman/listinfo/paraview
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20090114/b624ef3d/attachment.htm>


More information about the ParaView mailing list