[Paraview] Add support for PARAVIEW_EXTRA_EXTERNAL_PLUGINS?
Michael Jackson
mike.jackson at bluequartz.net
Wed Jan 14 11:09:55 EST 2009
Awesome. I have the same issues with keeping 2 CMake files for each
plugin. This eliminates that need and is less work for me. I vote keep
it/put it in.
Thanks for the excellent explanation.
_________________________________________________________
Mike Jackson mike.jackson at bluequartz.net
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Jan 14, 2009, at 11:04 AM, John Biddiscombe wrote:
> 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
>
>
>
>
More information about the ParaView
mailing list