[Paraview] Plugins for custom apps

[Eric E. Monson]

Hey Utkarsh,

I tried this and it worked beautifully on OS X, but I'm hitting a problem on Ubuntu. When I run ccmake it complains:

CMake Error at
 /home/emonson/Programming/ParaView_cvs/ParaView3/CMake/ParaViewBranding.cmake:
 254 (TARGET_LINK_LIBRARIES):
   Target "SMPVSlabClipDataSet" of type MODULE_LIBRARY may not be linked into
   another target.  One may link only to STATIC or SHARED libraries, or to
   executables with the ENABLE_EXPORTS property set.

   If you are developing a new project, re-organize it to avoid linking to
   modules.  If you are just trying to build an existing project, set
   CMAKE_BACKWARDS_COMPATIBILITY to 2.2 or lower to allow linking to modules.
 Call Stack (most recent call first):
   MSI_Strip3/CMakeLists.txt:42 (build_paraview_client)

This error is listed for both of the plugins I'm trying to build and link along with my branded PV. It doesn't list the problem for the Point Sprites plugin that I'm linking in but built along with my PV build. Both of the plugins use the standard ADD_PARAVIEW_PLUGIN() call in their CMakeLists.txt files. 

My build of ParaView on that machine has BUILD_SHARED_LIBS: ON (but VTK_USE_RPATH: OFF to make the install stuff work). It's 64-bit Ubuntu 9.10 and I'm using CMake 2.6 patch 4 and CVS ParaView from Jan 14.

I'll try using the "cmake backwards compatibility" to 2.2, but do you have any ideas about why this would work on OS X, but not on Ubuntu?

Thanks a lot,
-Eric


On Jan 27, 2010, at 3:07 PM, Utkarsh Ayachit wrote:

> Eric,
> 
> I am tempted to deprecate the OPTIONAL_PLUGINS and REQUIRED_PLUGINS. I
> think if a branded app needs a plugin, it should directly link against
> it (using TARGET_LINK_LIBRARIES or EXTRA_DEPENDENCIES in the
> build_paraview_client macro). and then use the PV_PLUGIN_IMPORT_INIT,
> PV_PLUGIN_IMPORT macros, as documented at the following link, to
> import the plugin into the application.
> 
> http://paraview.org/Wiki/Plugin_HowTo#Plugins_in_Static_Applications
> 
> Any opinions?
> 
> Utkarsh
> 
> On Mon, Jan 25, 2010 at 1:17 PM, Eric E. Monson <emonson at cs.duke.edu> wrote:
>> Hello,
>> 
>> I have a custom ("branded") app and a custom PV plugin. I'd prefer to keep the code for these separate, just for clean development, but I want the app to "know about" the plugin so it can package them together automatically.
>> 
>> I can compile both at the same time by putting them each in their own subdirectory, and having a root CMakeLists.txt simply specifying the names of those subdirectories. But, when I list my custom plugin in the app's OPTIONAL_PLUGINS, it doesn't get packaged with the app libraries. (PointSpritePlugin does, though, as I told it to.)
>> 
>> Is there some less-naive structure I should be giving my project rather than just two separate subdirectories (and accompanying CMake files) so my app will "know about" my plugin (and maybe so they can also be built into the same "build/bin" directory, kind of like when paraview is built)?
>> 
>> Also, for clarification, the notes on the wiki for Writing_Custom_Applications says that OPTIONAL_PLUGINS should use "name of the plugin specified in the add_paraview_plugin call", but PointSpritePlugin works and it's actually the project() name rather than the add_paraview_plugin() name (which is CSCS_PointSprite_Plugin).
>> 
>> Thanks a lot,
>> -Eric
>> 
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>> 
>> Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://www.paraview.org/mailman/listinfo/paraview
>>