plugin development commit

Hello

I’m upgrading the GenericIO plugin; it’s basically version 1.1 of the plugin I added in 2016/2017. Once everything is sorted out, I’d like 1.1 to be integrated into ParaView.

I used the github repo of paraview (master: GitHub - Kitware/ParaView: VTK-based Data Analysis and Visualization Application) to do my changes. Is that fine or should the changes be made to the superbuild? Also, how do I get the new plugin into ParaView? A merge request or something else …

Thanks

The superbuild will need changes to provide the newer GenericIO at least (BLOSC and sz are already there, so that should be pretty simple). There will need to be some tandem merging since I suspect either going first will cause the other to fail. We can set up the superbuild MR to build your paraview MR to test them together.

Which branch of the superbuild should I integrate it in? Is it master or something else?

Hi @zetwal

There is two things to do:

  1. Merge your changes into ParaView gitlab repository
  2. Update GenericIO in the ParaView superbuild

Lets focus on 1 for now.

First read this and follow the steps: https://gitlab.kitware.com/paraview/paraview/-/blob/master/Documentation/dev/git/develop.md

Then add your github repository as a new remote and checkout your branch.
Then push your branch to the gitlab remote
Then open a mr on gitlab.kitware.com/paraview/paraview and tag me on it.

Lets reconvene once we’ve reached that :slight_smile:

That sounds like a plan.

Version 1.1 of the plugin will require BLOSC and SZ. The genericIO reader just includes the source of BLOSC and SZ in its repo (using add_subdirectory in the CMakeLists.txt). However, Ben mentioned that this could cause issues and ParaView has these two. Are there examples where these two are used? I assume that I’ll be using find_package(SZ …), where should that point to?

Thanks

Just use find_package(SZ). It’s up to the builder (superbuild, vcpkg, etc.) to make the dependencies that should be used accessible.