[Paraview-developers] AUTOLOAD option is deprecated in ParaView 3.98 RC2

[Cory Quammen]

Utkarsh,

I just got everything to compile against ParaView 3.98.0-RC2 and
pushed my changes to github:

https://github.com/MADAI/MADAIWorkbench

In fact, in the current state of things, it turns out I can use
pv_plugin() and its AUTOLOAD option.

Briefly, here are the changes I had to make. Feel free to use this as
a basis for an entry in the future migration guide if you wish.

- Remove the inclusion of my Plugins directory via add_subdirectory.
The CMake macro pv_process_plugins() will add the Plugin directory as
well as the directories for all your plugins.

- Remove the CMakeLists.txt file in my Plugins directory because it is
no longer needed to list all the plugin subdirectories.

- Add a plugin.cmake file to each plugin directory with an entry like

pv_plugin( BinningFilter
  DESCRIPTION "Filter that discretizes points into a grid"
  DEFAULT_ENABLED
  AUTOLOAD
  )

Note that if you forget to add DEFAULT_ENABLED prior to configuring
the project for the first time, the plugin will be disabled and you
will need to either enable it through CMake by setting
PARAVIEW_BUILD_PLUGIN_BinningFilter to ON or wiping out your build
directory and configuring again with CMake.

I want all the plugins to load at program startup, so I add AUTOLOAD
to each pv_plugin call. This mechanism works as expected.

- Remove AUTOLOAD from calls to add_paraview_plugin()

- In the CMakeLists.txt file for your application, call
pv_process_plugins(), passing the source and binary plugin directories
as arguments.

All in all, the changes weren't that substantial.

Cory

On Thu, Nov 15, 2012 at 1:26 PM, Cory Quammen <cquammen at cs.unc.edu> wrote:
> Utkarsh,
>
> On Thu, Nov 15, 2012 at 12:16 PM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>> Cory,
>>
>>> I have at least one plugin packaged with our branded version of
>>> ParaView where the AUTOLOAD mechanism is used. For that plugin, I
>>> don't want to rely on the user checking the box in the GUI. So I think
>>> the option is still useful.
>>>
>>
>> Hmm, okay. I have been wondering what support could we provide to ensure
>> that plugins for branded applications can be loaded automatically. Can you
>> give some more details on who your application is setup, maybe we can come
>> up with something cleaner.
>
> I had been relying on the .plugins file that I was able to write with
> a macro (or function) called write_plugins_file() that is no longer in
> ParaView master. I think the .plugins file is now written by
> pv_process_plugins. Including the .plugins file in my installer was
> all I needed to get the autoload plugin to work.
>
>> When you generate binaries for your users, do you
>> package your plugin's shared libraries with the application as well (similar
>> to what ParaView does for plugins in the ParaView source)?
>
> Yes, it is a self-contained installer with the branded application and
> all plugins. You can take a look at the CMakeLists.txt file with most
> of the packaging stuff here if you are curious:
>
> https://github.com/MADAI/MADAIWorkbench/blob/master/Application/CMakeLists.txt
>
> It's a bit of a hack job, but it works for Mac and Windows. Look
> around line 160 for the plugin-specific stuff. Note that this compiles
> against ParaView 3.14.1 and won't configure yet with 3.98-RC2 (I'm
> working on it).
>
> Thanks for you time and interest,
>
> Cory
>
> --
> Cory Quammen
> Research Associate
> Department of Computer Science
> The University of North Carolina at Chapel Hill



-- 
Cory Quammen
Research Associate
Department of Computer Science
The University of North Carolina at Chapel Hill