I am really intrested in using this feature, does anybody have an example of using PARAVIEW_EXTRA_EXTERNAL_MODULES with a custom GUI?<br><br><div class="gmail_quote">On Wed, Jan 14, 2009 at 11:09 AM, Michael Jackson <span dir="ltr"><<a href="mailto:mike.jackson@bluequartz.net">mike.jackson@bluequartz.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
<br>
Thanks for the excellent explanation.<div class="Ih2E3d"><br>
_________________________________________________________<br>
Mike Jackson <a href="mailto:mike.jackson@bluequartz.net" target="_blank">mike.jackson@bluequartz.net</a><br>
BlueQuartz Software <a href="http://www.bluequartz.net" target="_blank">www.bluequartz.net</a><br>
Principal Software Engineer Dayton, Ohio<br>
<br>
<br>
<br></div><div><div></div><div class="Wj3C7c">
On Jan 14, 2009, at 11:04 AM, John Biddiscombe wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mike<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>
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.<br>
<br>
JB<br>
<br>
<br>
<br>
<br>
</blockquote>
<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>