CMake APIs for plugins, clients, and server manager XML files have been updated and made much more uniform. As with VTK, there is inline documentation with the code which will eventually be extracted and added to ParaView’s Doxygen documentation.
ClientServer wrapping uses the same patterns as Python and Java now (plugins still get it “for free”).
ServerManager XML files can now be attached to other modules (though this is not done right now). For example, ParaView can add a proxy to the VTK::IONetCDF module and it will be used properly. This is in contrast to the way it is done currently where the XML file is associated with ParaView::ServerManagerApplication and it just hopes that VTK::IONetCDF is available in some way for the ClientServer wrappings.
ServerManager, ClientServer, and plugins are built in such a way to provide targets for proper initialization (e.g., ParaView makes a paraview_server_manager target for all of its XML outputs). See the documentation for usage details.
The details for VTK are largely the same as for ParaView except:
Only a handful of plugins have been updated at the moment; the rest will be updated after the initial merge.
Examples are not updated yet.
The catalyze.py and the edition manifests are not yet updated.
Some other tasks that need to be done once it lands:
The ParaViewCore/Testing directory needs integrated. As far as I can tell, it isn’t used on master either.
The XML tests should be sorted a bit better.
ServerManager XML files should be split to be associated with the modules providing the classes behind the proxies (the new CMake API for this makes it much easier).
ParaView also has lots of unused .sha512 data files laying around. Whether to remove them from the repo or add tests to use them should be determined.
Some modules still have optional public dependencies. These should be resolved.
The only ported ones are those in ParaView itself so far. External plugins night need some more CMake code (e.g., find_package(ParaView) and that might still have issues), but I don’t think they’ll need too much.
Did you look at those in ParaView? In order to be wrapped in ClientServer, a module must be created. The vtk_module_scan and vtk_module_build boilerplate in the plugin’s CMakeLists.txt will likely be refactored out and made simpler with a new function the plugin CMake API provides, but for now it’s still necessary.
Yeah, paraview-config.cmake needs some other love as well. Those files should actually just be handled with the find_package(VTK) that should be there. Once I have the buildbots happier, I’ll focus on that. ParaView has been a rockier merge since my machines test much less of ParaView comparatively and I hadn’t tested plugins on other platforms…
The big issues right now is plugin loading on Windows (debugging now) and Python on Linux not working on the buildbot (next). I’m working on the build failures while I’m getting builds to debug for those. Hopefully it won’t be more than a couple more days…
That’s the vtable for the plugin class. Is the generated source missing a dtor or another function which is declared in the header, but not in the source?