[Paraview] Add support for PARAVIEW_EXTRA_EXTERNAL_PLUGINS?

[Robert Maynard]

I am really intrested in using this feature, does anybody have an example of
using PARAVIEW_EXTRA_EXTERNAL_MODULES with a custom GUI?

On Wed, Jan 14, 2009 at 11:09 AM, Michael Jackson <
mike.jackson at bluequartz.net> wrote:

> 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
>>
>>
>>
>>
>>
> _______________________________________________
> 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/4973dda8/attachment.htm>