[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