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

[Cory Quammen]

By the way, it seems strange to have to use both a CMakeLists.txt file
and plugin.cmake to define a plugin. It would be nice if everything
could go in one or the other.

Cory

On Thu, Nov 15, 2012 at 3:20 PM, Cory Quammen <cquammen at cs.unc.edu> wrote:
> 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



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