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 <[email protected]> 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 >> _______________________________________________ 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
