First own plugin integrated into custom app based on PV 5.7 RC2

At the end of this post I come to a likely mistake in the current new RC2 build setup.

Before that I am just explaining some of the obstacles that a “user developer” may run into if he tries to work with the new build setup - just in case somebody is interested.

Since about a couple of days I am very busy trying to port a custom application with plugins to the new and much more modularized and transparent build setup that comes with PV 5.7 and which is now available as RC2. In other threads I was already asking questions, and this is now about the last step of integrating a first plugin into the custom application.

Generally speaking, a first problem with the entire setup is how to understand it at all in the first place! There are lots of automatisms in place, but once they do NOT immediately what you expect it takes a very long time to find a solution. The example custom applications and plugins are very helpful, but they do not show how to finally put things together.

So I first had to struggle with the problem of coming from a project like “clone1” - which is basically “Paraview with nothing”, i.e. with no plugins - to something real - loading the base and optional plugins of PV as far as they are needed.

Next I used the “elevationfilter” as a base to rework one of my own plugins. Building that ElevationFilter was not a problem at all. However, when added to the custom application, neither my own nor the ElevationFilter ever produced any shared library at all! Until after many hours of CMake code digging I found out that I need to set BUILD_SHARED_LIBS to ON because otherwise you will NEVER get any shared libraries for either modules or plugins! Looks trivial once you know it - but it is extremely hard to find out if it is not the case - and only this is the reason why I am telling this story at all!

With that it was possible to build the ElevationFilter plugin and my own within my custom project. They did not auto-load, but could both be loaded manually. However, while the ElevationFilter worked as advertised, my own crashed once it was supposed to do anything. The first assumption that it is some bug in my own code was after a while shown to be wrong: Somehow the “client server wrapping” did not work - but how the hell are you supposed to debug such a thing?

Again it was many hours of code digging and research until I realized that in the vtk.module file which is part of the new module system, the plugin MUST contain the line

DEPENDS VTK::FiltersCore

while in my own plugin I had tried to make it

PRIVATE_DEPENDS VTK::FiltersCore

…because I thought it might be good practice to have things “private” that are not supposed to be exported…

Finally the question: How to tell the custom application to auto-load the new plugins? Up to PV 5.6 this was done with some “magic macros”, but now this is supposed to work in a more elegant way - just adding the plugins to the paraview_add_client in a REQUIRED_PLUGINS section - and the custom application will try to load the named plugins - nice and much more elegant! (This is btw. also how loading optional plugins from PV is working). However - it did not happen.

Again after MANY hours of research I think now that there is actually a bug still in the new build setup system. The point is that with “logging” turned on I could see that my custom app actually TRIED to load the plugin, but it was looking for it in the wrong place - actually trying a long list of possible locations!

By default the plugin would end up in a subdirectory like

lib64/<PluginName>

However, such a location is not considered by the automatic loading! And also I would prefer if things are not so much “spread” around the place, but rather kept together. So told the paraview_build_plugin function that I want the libraries output into the same directory as the executables, which is in

bin

You can still specify a subdirectory there, but this I set to “” which is also the default anyway. But all this did not help: the plugins always ended up in subdirectories like

bin/<PluginName>

Which is clearly not what anybody would expect after the above specifications! And also the automatic plugin search never tries such a subdirectory.

Finally I found the place where that additional subdirectory level slipped in - and this is what I think is probably a mistake: the paraview_add_plugin inserts this subdirectory level for no obvious reason in two places, so I had to delete (or comment out) the following two lines:

CMake/ParaViewPlugin.cmake(593)
CMake/ParaViewPlugin.cmake(932)

With this everything worked fine finally!

I have no idea if this additional subdirectory level may in some situations be important to avoid clashes or whatever, but then the problem would have to be solved at the level of the auto-loading mechanism - in a way that the plugins can be finally found!