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 < [email protected]> 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 [email protected] > 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 > [email protected] > http://www.paraview.org/mailman/listinfo/paraview >
_______________________________________________ ParaView mailing list [email protected] http://www.paraview.org/mailman/listinfo/paraview
