John, <br><br>I think this would be a very good idea.<br><br>So if I put <br>PARAVIEW_EXTRA_EXTERNAL_PLUGINS : vtkCSCSFluent<br>then it will prompt for a path and I just give it the path to the source for example : vtkCSCS/vtkFluentvtkCSCS/ <br>
I assume that it will then use the cmake file that's in vtkCSCS/vtkFluent/pv3-plugin ?<br><br>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 ?<br>
<br>Regards, <br>Jacques<br><br><div class="gmail_quote">2009/1/14 John Biddiscombe <span dir="ltr"><biddisco@cscs.ch></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mike<div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
what is the difference between setting my Module as a PARAVIEW_EXTRA_EXTERNAL_MODULES vs PARAVIEW_EXTRA_EXTERNAL_PLUGINS?<br>
</blockquote>
<br></div>
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.<br>
CMake picks up the file 'NAME'ParaViewImport.cmake and uses it for the sources<br>
<br>
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.<br>
<br>
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<br>
<br>
Currently I have 3 setf for each module, and maintaining them is a pain.<br>
1) compile as a vtk filter, (use cmakelists.txt)<br>
2) compile as a plugin (use pv3-plugin/cmakelists.txt)<br>
3) compiles as external_module into paraview (use 'NAME'ParaViewImport.cmake)<br>
<br>
too much work.<br>
3) is no longer required by me.<br>
2) is nice because changing a plugin is a quicker make than changing paraview source<br>
2) also allows me to use my new external_plugins to compile at pv-compile time just like I used to with 3)<br>
<br>
I hope this thread is finished now.<div><div></div><div class="Wj3C7c"><br>
<br>
JB<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
ParaView mailing list<br>
<a href="mailto:ParaView@paraview.org" target="_blank">ParaView@paraview.org</a><br>
<a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/mailman/listinfo/paraview</a><br>
</div></div></blockquote></div><br>