Just trying to compile and start a custom app with the new version 5.8 - and the good news is that after one day it is already compiling and starting without complaint! (Except some of my view and representation plugins seem to need some fixes…).
Now it looks to me like the plugin loading function is somehow changed, and I do not understand how! My application does find my own plugins, but it has trouble to find some optional ParaView plugins like ArrowGlyph that I want to load as well. With PARAVIEW_LOG_PLUGIN_VERBOSITY=INFO I can see that it finds them - in my old build tree with ParaView 5.7! But then has trouble to load them in version 5.8…
And if I rename that old build tree (to make it “invisible”) It tells me that the dlls do not exist at all. Which is definitely not true: ArrowGlyph.dll and the others are present in the build tree of ParaView 5.8 which resides directly next to the PV 5.7 tree! And yes, I also adapted the PATH in such a way that it points now to the directory where also paraview.exe resides, together with many dlls like vtkCommonColor-pv5.8.dll and many others. Plugins are “below” that one, in \paraview-5.8\plugins where they seem to belong.
I have no idea where the program finds a “hint” to the old pv570 tree - and also I see no way to track the searching process: In PV5.7 I could generate some kind of “plugin search tracking output” where you saw directly which directories were tried, while now I am only told things like:
( 0.503s) [paraview ] vtkPVPluginTracker.cxx:414 INFO| Trying to locate plugin with name ArrowGlyph
( 0.503s) [paraview ] vtkPVPluginTracker.cxx:442 INFO| Invalid filename= setting for ArrowGlyph; the given path (ArrowGlyph.dll) must exist.
( 0.503s) [paraview ] vtkPVPluginTracker.cxx:461 INFO| Failed to locate file plugin ArrowGlyph
Am I simply supposed to add also the plugin DLL directory to the PATH and rely on the Windows facilities to find the DLLs? No - this does not work either! In the past ParaView had it’s own sophisticated search strategy for these things.
One more thing: I changed the ParaViewPlugin.cmake in such a way that it does not generate extra folders for each and every plugin. I did that already with PV 5.7, and it worked for me, but maybe there are some changes in PV 5.8 that are making this approach impossible?
In short: If there is any kind of documentation about plugin loading strategies in 5.8 I am sure I will find my way!
Did you add the ParaView::paraview_plugins target to your paraview_client_add(PLUGINS_TARGETS) argument list? That should get them found automatically (it basically adds information to the client.conf beside your client application).
There was a minor change where PV_PLUGINS_PATH will now look in for plugin/plugin.dll in each plugin entry (the plugin name coming from the directory name).
Do you have a stale path in the .conf file for your app? Stale configuration info (pass -dr to not load that information)?
PV_PLUGIN_DEBUG=1 has worked for me (though it’s been replaced, it still works and I haven’t internalized the new one).
The extra directories are to allow plugins to have other things beside them and still act as a single unit (e.g., module libraries, data files, etc.).
Looks like the relevant changes are in the function vtkPVPluginTracker::LoadPluginConfigurationXML(vtkPVXMLElementRoot* root, bool forceLoad) which is called by LoadPluginConfigurationXMLFromString(…) which I am using to load plugins already in the MainWindow constructor of my custom application. And this I am doing in order to have a derived main “render view” ready when I make it the default view a few lines further.
The old functionality was using some vtkLocatePluginOrConfigFile() function to do some hardcoded “magic” for finding the plugins, while now there seems to be some “hint” involved which is by default set to “nullptr” - which has the effect that no “magic” will be applied at all.
Not that I ever fully understood what the old “magic” was actually all about, but somehow I managed to get it working. Now it is broken, but I know at least where to look in order to find another pragmatic way to get what I need - with or without hints or magic!
That logic I understood pretty well, but I preferred to have the more “simple” approach of having all plugins next to each other in a single folder - most of them being just one dll anyway!
Only load the own custom plugins with the LoadPluginConfigurationXMLFromString(…) function - which are located in the same directory as the exe file anyway.
Load the optional ParaView plugins through the REQUIRED_PLUGINS section of the paraview_client_add() call in the appropriate CMakeLists.txt file
And this seems to work now perfectly in the way I need it - without too much “hacking” and fiddling in the PV internals!