How to ensure that "client-server wrapping is properly initialized"?

What would you do if you get the following error message - after the PV has crashed:

vtkSISourceProxy (0x296eb70): Failed to create ‘vtkAtgBlockModelReader’. This typically means that ParaView does not know about the request class to create an instance of if. Ensure that it has been correctly wrapped using the client-server wrappers and the wrapping has been initialized. Note class names are case-sensitive. Check for typos. Aborting for debugging purposes.

  • The good thing is that the message even contains some kind of “explanation” of the problem.

  • The bad thing is that it is not helpful at all! Because examples can tell you what to do, but they do not explain anything!

In other words: tons of vtk.module files are in place, also paraview.plugin files, then CMake function calls are more or less cloned from the given example plugins - but all this is not explaining what actually “client-server wrappers” are and how “wrapping has to be initialized” - because all this is hidden behind tricky automatisms. Of course also not all the plugins are exactly following the patterns of the given examples - simply because they are doing different things. So adaptations were done with supposedly “reasonable” changes. But they might be wrong of course!

Or in even other words: What to do in order to find then root cause of such a problem?

Note that all the C++ and XML code has already been working nicely with PV 5.6, so it is all about the new CMake setup for version 5.7.

The “Client/Server wrapping mechanism” is indeed an automatic mechanism that generate a wrapper around VTK class so they can be controlled by the proxies on the client.

The mechanism is creating dedicated server manager class in your build directory, they are named
vtkMyClassClientServer.cxx, look for them in your build, try your hand at an already working example plugin to understand how it is supposed to look before taking a look into your own generated class and see if they are not correct.

In any case, this looks like a standard case of incorrect export. You class is included in a VTK module and for that reason should contain a line like this one in the class declaration :
class MYVTKMODULE_EXPORT vtkMyClass : public vtkClass

If that’s not the case, well you will need to share the vtkMyClassClientServer.cxx file.

This project adaptation project from v5.6 to v5.7 is really gradually getting out of control: Almost four weeks full time, and not even the “base project” successfully ported - not even think about the extended projects and the “superbuilds”…

Actually I could not find any *ClientServer.cxx files in my generated directory trees, while in the “elevation plugin” example they do exist as explained. But I had “dared” to apply some changes to the setup in the sense that I

  • generated only 4 or 5 modules containing the code for quite a number of plugins each, with vtk.module and CMakeLists.txt files
  • then generated the about 30 plugins, with paraview.plugin, CMakeLists.txt and xml files, and referring to the common modules

Now the problem is that there is little chance to do anything in a logical way - just copy, paste and adapt from the example code, and for the rest guessing and some *.cmake code reading, including some short explanations there.

So since I did not know what really went wrong that I did not have *ClientServer.cxx files, I spent now 3 days reorganizing everything again. It is now about 30 plugins, each of them consisting of an own “module” and a “plugin” part - exactly like the elevation example - as far as possible! And now I am getting at least a lot of *ClientServer.cxx files.

For the following cases it must be said that they were ALL working fine in the setup based on version 5.6, so it is clear that the uncorrect application of the new build setup is the problem.

Cases:

  1. a view that is derived from the RenderView, consisting of only an XML file, a paraview.plugin and a CMakeLists.txt. In the latter a SERVER_MANAGER_XML tag was added to the paraview_add_plugin because that plugin has no “module” - where in all the other cases the xml is located.

-> that plugin works nicely, and already worked without any *ClientServer.cxx files (which gave me the totally wrong impression that I am “almost there”…)

  1. two “filters” that take an unstructured grid as input and generate a new one, with additional calculated attributes. Here the setup is exactly with the “elevation” plugin, and they are working now.

  2. a view that is derived from the SpreadSheet View that includes a plugin and a module, the latter with a C++ class. The setup is same as with “elevation filter”, and *ClientServer.cxx files are generated, both for the plugin and for the module, like for the two previous classes. However, the “plugin” CS.cxx contains only an empty …_Init() function, while the same cxx of one of the working plugins is much more code. The module CS.cxx files of both the table view and the “working filter” is in both cases just that empty …_Init() function.

-> that table view crashes the program if such a view is supposed to be shown, with the error message

Failed to create ‘vtkAtgTableView’. This typically means that ParaView does not know about the request class to create an instance of if. Ensure that it has been correctly wrapped using the client-server wrappers and the wrapping has been initialized. Note class names are case-sensitive. Check for typos. Aborting for debugging purposes.

  1. property widgets. I tried to collect them in one module that I would like to share between several plugins. However, these property widgets do not show up, without any comment or message. For this module I have a vtk.module file with NAME, LIBRARY_NAME and DEPENDS. And then I had to add a EXCLUDE_WRAP line at the end - because otherwise the build failed because the vtkWrapHierarchy tool had some problems. But that way also no *ClientServer.cxx file was generated - and this is maybe then also the reason why the widgets could not be found…

-> somehow I will have to make that vtkWrapHierarchy tool happy - but how?

  1. a couple of domains. I tried to collect also these in a module, and I wrote a vtk.module for it, with NAME, LIBRARY_NAME and DEPENDS. And without that EXCLUDE_WRAP line because there was no complaint. However, *ClientServer.cxx files were not generated, and also the domains were never found. Instead I always have a message in the plugin right after my program has started (which I currently always do with -v=TRACE and PARAVIEW_LOG_PIPELINE_VERBOSITY to MAX):

    ( 1.096s) [paraview ] vtkSMProperty.cxx:553 ERR| vtkSMStringVectorProperty (0x33100e0): Could not create object of type: vtkSMRenameableArraysDomain. Did you specify wrong xml element?
    ( 1.127s) [paraview ] vtkSMProperty.cxx:553 ERR| vtkSMStringVectorProperty (0x3c7b6b0): uld not create object of type: vtkSMTonnageArraysDomain. Did you specify wrong xml element?
    ( 1.128s) [paraview ] vtkSMProperty.cxx:553 ERR| vtkSMStringVectorProperty (0x25b8800): Could not create object of type: vtkSMPitArraysDomain. Did you specify wrong xml element?
    ( 1.128s) [paraview ] vtkSMProperty.cxx:553 ERR| vtkSMStringVectorProperty (0x3c854e0): Could not create object of type: vtkSMCategoryArraysDomain. Did you specify wrong xml element?
    ( 1.246s) [paraview ] vtkSMProperty.cxx:553 ERR| vtkSMStringVectorProperty (0x3df8030): Could not create object of type: vtkSMRenameableArraysDomain. Did you specify wrong xml element?
    ( 1.247s) [paraview ] vtkSMProperty.cxx:553 ERR| vtkSMStringVectorProperty (0x3df6460): Could not create object of type: vtkSMTonnageArraysDomain. Did you specify wrong xml element?
    ( 1.247s) [paraview ] vtkSMProperty.cxx:553 ERR| vtkSMStringVectorProperty (0x3f55c90): Could not create object of type: vtkSMPitArraysDomain. Did you specify wrong xml element?
    ( 1.248s) [paraview ] vtkSMProperty.cxx:553 ERR| vtkSMStringVectorProperty (0x3d18a10): Could not create object of type: vtkSMCategoryArraysDomain. Did you specify wrong xml element?

Well, I did not create any “xml element”, because so far I learned that for specifying comains it is good enough to have a class named vtkSM ready. But while that was indeed good enough in my previous setup, now it looks like the classes are not found any more!

Overall, it looks like all my “plain modules” (with just a number of classes with code that plugins and other code is calling) is not getting such *ClientServer.cxx classes, and maybe this is also normally not required if the code is just for being called by other C++ code!?

I know that this is still a LONG list of problems - and still I would be very happy if some friendly person who knows that new v5.7 build setup system could give me some hints for proceeding further!

Because this I understand by now: I am still FAR from getting the whole thing up and running! While still I WOULD be happy if I could finally get there - because I hope to end up with a setup with some more transparency about dependencies etc.

Because this plugin sounds like a client only plugin, which does not require a server manager wrapping.

a view that is derived from the SpreadSheet View that includes a plugin and a module, the latter with a C++ class. The setup is same as with “elevation filter”, and *ClientServer.cxx files are generated, both for the plugin and for the module, like for the two previous classes. However, the “plugin” CS.cxx contains only an empty …_Init() function, while the same cxx of one of the working plugins is much more code. The module CS.cxx files of both the table view and the “working filter” is in both cases just that empty …_Init() function.

Sounds like a export issue. Make sure your VTK classes are exported correctly. Check the EXPORT line near the class name.
Take a look into plugin that declare new views as well.

property widgets. I tried to collect them in one module that I would like to share between several plugins. However, these property widgets do not show up, without any comment or message. For this module I have a vtk.module file with NAME, LIBRARY_NAME and DEPENDS. And then I had to add a EXCLUDE_WRAP line at the end - because otherwise the build failed because the vtkWrapHierarchy tool had some problems. But that way also no *ClientServer.cxx file was generated - and this is maybe then also the reason why the widgets could not be found…

Interesting idea. I would need to check that it is working with example plugins.

a couple of domains. I tried to collect also these in a module, and I wrote a vtk.module for it, with NAME, LIBRARY_NAME and DEPENDS. And without that EXCLUDE_WRAP line because there was no complaint. However, *ClientServer.cxx files were not generated, and also the domains were never found. Instead I always have a message in the plugin right after my program has started (which I currently always do with -v=TRACE and PARAVIEW_LOG_PIPELINE_VERBOSITY to MAX):

E̶X̶C̶L̶U̶D̶E̶_̶W̶R̶A̶P̶ ̶h̶a̶s̶ ̶n̶o̶ ̶e̶f̶f̶e̶c̶t̶ ̶(̶s̶i̶n̶c̶e̶ ̶P̶a̶r̶a̶V̶i̶e̶w̶ ̶5̶.̶0̶ ̶i̶ ̶t̶h̶i̶n̶k̶)̶.̶ ̶T̶h̶e̶r̶e̶ ̶s̶h̶o̶u̶l̶d̶ ̶b̶e̶ ̶C̶l̶i̶e̶n̶t̶S̶e̶r̶v̶e̶r̶ ̶f̶i̶l̶e̶.̶ ̶I̶f̶ ̶t̶h̶e̶r̶e̶ ̶a̶r̶e̶ ̶n̶o̶t̶,̶ ̶t̶h̶e̶n̶ ̶s̶o̶m̶e̶t̶h̶i̶n̶g̶ ̶i̶s̶ ̶w̶r̶o̶n̶g̶ ̶i̶n̶ ̶y̶o̶u̶r̶ ̶e̶x̶p̶o̶r̶t̶s̶ ̶a̶r̶e̶ ̶y̶o̶u̶r̶ ̶C̶M̶a̶k̶e̶L̶i̶s̶t̶s̶.̶ ̶O̶n̶c̶e̶ ̶a̶g̶a̶i̶n̶,̶ ̶c̶h̶e̶c̶k̶ ̶e̶x̶a̶m̶p̶l̶e̶s̶.̶

Not true, see @ben.boeckel message below.

Ok, thanks again Mathieu for your comments!

The “key word” that I extracted from your previous mail was “client server wrapping” - and that it has to do with the generation of *ClientServer.cxx files. Plus the fact that they are generated “automatically”.

Only I still do not know where this automatism is actually sitting, i.e.: which of the many “magical *.cmake functions” are doing the job, so I can make sure that they are properly called! I understand so far that many of the “high level functions” do it indirectly, but which ones?

Also I do not unserstand yet which ones of the classes really need this kind of “wrapping” in order to be found. Because I assume that some of the operations do still rely also on “common linking”!?

Now in that last comment from you I read “… maybe only needed on the client, not on the server …”, which in turn makes it unnecessary to have that wrapping in place - right?

But then this must be true for all the “view” and “representation” classes, and also for the property widgets - right?

A new “key word” I am reading now from this last post is that I should look for “proper EXPORT” - which is indeed for me still a secret: what does it actually does?

I mean, I see that “targets” are being “exported” in the CMake language. “Normal” make systems have “key word targets” (like “all”, “clean” or the like) and targets that are actually files to be generated. To some degree it seems to be the same for CMake, but then there seems to be a mechanism that also allows to pull all kinds of settings with a “target” that is being “exported” - like not only the name of the file to be generated, but also things like include path, settings for the compiler, link libraries for proper linking, etc.

So far my guess (now knowledge!!) is that it might have to do with the “properties” that you can specify?

Side remark 1: What would be a dream in CMake would be functions that can be used during debugging, like:

  • “give me a list of all currently known targets”
  • “give me a list of all properties of a target”
  • “give me a list of all currently defined variables”

With such things it would be much easier to find a way through the many “magical functions” that are making up a complex CMake setup - and do adaptations not by guessing, but based on logical reasoning!

Side remark 2: In any case I am always very happy if I am back to “normal C++ programming” - because there I can indeed work with logical thinking instead of “guessing along the lines of key words” - like “client server wrapping” or “target export” etc. But please do not take such negative statements personally! I love the power of both Paraview and CMake, and I have a lot of respect for the work that a number of people are putting into these tools! And I am happy with any kind of “straw” that I can find - like “key words” that trigger guess work - because from time to time even some understanding makes it’s way into my limited brain… And I even like the new CMake setup for Paraview because I still have the hope that I will have a much more transparent and understandable project setup also for my own software - eventually!

client server wrapping” […] I understand so far that many of the “high level functions” do it indirectly, but which ones?

  • The classes must be in a vtk module
  • this vtk module must be included in the MODULES and MODULE_FILES of a plugin

Also I do not unserstand yet which ones of the classes really need this kind of “wrapping” in order to be found. Because I assume that some of the operations do still rely also on “common linking”!?

Any vtk classes listed in your XML files which is not part of VTK.

Now in that last comment from you I read “… maybe only needed on the client, not on the server …”, which in turn makes it unnecessary to have that wrapping in place - right?

Yes, but that concern plugin that run only client side, like GUI plugins, with an no XML files or with an
XML file that only mentions vtk* classes which are part of VTK, like the PropertWidgets example.

But then this must be true for all the “view” and “representation” classes, and also for the property widgets - right?

No, that is not true. Views and Representations plugins (most of the time) have classes that are vtk*, in a module and are wrapped. see BagPlotViewsAndRepresentations plugin for an (complex) example.

A new “key word” I am reading now from this last post is that I should look for “proper EXPORT” - which is indeed for me still a secret: what does it actually does?

It export the symbol of the classes into the .dll. Afaik, it matters only on windows. See here for more generic info :


@ben.boeckel will know more.

This is unrelated to cmake or properties.

Side remark 1

Fell free to ask on the CMake mailing lists

Thanks also for that one! Besides other things I am learning that you are talking about another “export” than what I understood in your previous mail: I thought you were talking abut the “export” feature in the CMake system!

Now I see that you are talking about that export nonsense in Windows, but I am happy that I already fought my way through that one - and understood the way how it is handled with CMake functionality! And also I understood that I had to include some extra CMake module in the past, while now the generation of the proper “export include” is automatic with the module and/or plugin generation functions.

So basically ALL my classes that I want to export from shared libraries are having some NNN_EXPORT macro in front of them, and a proper “include” that generates that Windows nonsense.

Until now I am doing the entire work on my Linux system, but of course I will still have to port to Windows, where the importing of libraries seems to happen earlier, so many missing external dependencies are showing earlier than on the Linux system. And of course the “superbuild” I am only maintaining for Windows because all my customers are so far using that system.

This is about proper handling / wrapping of property widgets.

Actually I am trying to generate one module & plugin that contains only 3 properties that are supposed to be shared between different plugins, so it makes no sense to include them into their code, possibly even several times.

I am using now the “standard setup”, with a plugin directory containing a paraview.plugin file, a CMakeLists.txt file with a paraview_add_plugin call, plus a module directory. In that module directory there is the entire source code and the Qt stuff (that so far seems to work for me with the new AUTOMOC stuff etc.), plus a vtk.module file with the vtk_module_add_module call (plus some Qt related stuff).

There is not xml file because - what to put in there for only property widgets?

So far the CMake run ends with a “syntax error”, indicating the first class forward declaration in a header file as an “syntax error” that comes from the vtkWrapHierarchy tool.

Looking into a Paraview module that includes also property widgets I find the Qt/ApplicationComponents folder, also with a vtk.module. In that latter I find an additional last line: EXCLUDE_WRAP

If I append that also to my property widgets vtk.module, then the first error message goes away, but the paraview_add_plugin call is now complaining: “No modules given to be wrapped”.

Well yes, this is true of course: I turned it off!

Before my latest rearrangement, that module with the property widgets was just a module, no “plugin” related to it. At that time I did not get this last error message - because paraview_add_plugin was never called and both the cmake run as the entire compilation and build went smoothly, including the generation of a shared library.

But then the property widgets were never found by any filter or whatever class!

Now I am again a bit lost:

  • should I add some kind of xml file - but with what content?
  • do I have to remove the plugin stuff again, but instead do something that the shared library is properly linked to the other plugins that need the property widget?
  • and if yes - how do I achieve that proper linking?

Yes, proceeding in very small steps - and happy for every little helpful hint that somebody might provide!

One good news: The domains are now also not any more in a “plain module”, but in a plugin with module - and it looks like they are found now!

Interesting thread, let me drop my 5 cent here:
EXCLUDE_WRAP in your vtk.module file effectively excludes wrapping not only for other languages, but also from ClientServer files generation (aka *ClientServer.cxx mentioned here). Killed a day to find it out. Sadly, internal documentation about ECXLUDE_WRAP is not really accurate.

Still a mystery for me: how can I get those *ClientServer.cxx files, but DO NOT engage in wrapping classes to be used from python?

For example, my module have Qt-related classes, and I will definitely have errors when wrapper will try to build hierarchy… unless I add this to module’s CMakeLists.txt:

set(${vtk-module}_NO_HeaderTest 1)
?

I think I figured that one out by now: use SOURCES instead of CLASSES!

Explanation: actually it is the HEADERS that are the input for wrapping, and CLASSES is just a short version of

SOURCES mysource.cxx
HEADERS mysource.h

But now if you write for a class the following:

SOURCES mysource.cxx mysource.h

then you will have a dependency of both header and source code, but without a HEADERS entry you will not get wrapping for that class.

(This I am explaining not as an expert, but with some risk of talking nonsense: it is my current “state of the research”, so please correct and you will bring me also further!)

Writing like this
SOURCES mysource.cxx mysource.h
will give you nothing more than a cmake build dependency of target on 2 files (if either changed - target will be rebuilt).
BUT, I appreciate your note on HEADERS importance for wrapping, so i guess using CLASSES is pretty cool.
I have another one thing to note.
vtk_module_add_module description in source (vtkModule.cmake) is inaccurate in this part:
The PRIVATE_ arguments are analogous to their non-PRIVATE_ arguments, but the associated files are not installed or available for wrapping.
You MUST have SOURCES argument for this command, because if you write, eg

vtk_module_add_module( MyModule
PRIVATE_CLASSES ${pclasses}
PRIVATE_SOURCES ${psources}
PRIVATE_HEADERS ${pheaders})

you’ll get a configuration error complaining that module does not have any sources.
So SOURCES argument here is mandatory.

I have a guessing, that if you want to hide some classes from wrapping - put them into PRIVATE_* arguments. Qt classes, simple c++ classes and so on. They will be excluded from wrapper hierarchy.
Above was addressing your words “So far the CMake run ends with a “syntax error”, indicating the first class forward declaration in a header file as an “syntax error” that comes from the vtkWrapHierarchy tool”. Hope it helps.

Last one: one MUST have my_class.cxx and my_class.h files exactly with those extensions to be used for CLASSES argument. If you have a my_class.cpp - error again, “no source found” but with a tip, that different extensions were tried. No, they were not. Just *.cxx allowed at the moment.

Breakthrough!!!

Not everything is fully tested yet, and I already see that some plugins are still not working yet, but it looks like a major breakthrough is now reached! So I want to share it here.

And it is not the XML file, not any EXCLUDE_WRAP or whatever: the key is in the vtk.module file!

Symptom: plugins do compile and build without trouble, also they are loaded - and once they should do their job, they are crashing with that fatal message that “client server wrapping is not initialized”. The only problem is then: after learning about how to successfully write PV plugins, currently mostly from examples (and the one or other friendly hint from experts!) in a rather “top level” way, such a message from the “lowest level” is hard to follow - because there is a long way to go from that top level to the bottom of how things are working. But without that, a solution cannot be found!

First of all, turning on the maximum tracking and logging is important:

  • define an environment variable PARAVIEW_LOG_PIPELINE_VERBOSITY and set it to MAX
  • start the program with -v=TRACE as command line parameter

On top of that, I had to insert a number of vtkWarningMessage() commands into the ParaView code - in order to see what is actually going on in the different functions (and of course recompile Paraview then). This is important because there are thousands of plugins loaded before the own set of plugins is handled - which is far beyond common debugging with a debugger.

Basically plugins are first found and “registered”. That basically means: an initialization function is put into a list of plugin initialization functions. If this does not work, the program will complain about “not a proper plugin”, and otherwise it will keep the plugin.

Next, I am “loading” the plugins from the main window constructor of my application. For some unknown reason this triggers another round of searching for the shared library file of the plugin. (I did not do further research about this because it worked already long ago for all my plugins, plus the optional PV plugins that I decided to include into my application.)

With this, all the plugins are visible in the Plugin manager and marked as “loaded” - which gives the impression of a full success - but this is totally wrong! Only now the famous “client server wrapping” will hit - at the moment that the plugin is first being used for some functionality.

At that moment, the vtkSIProxy::CreateVTKObjects() function tries to create an object from one of the classes in the plugin, and for that it tries to find a “new instance function” in a list of such functions - and fails if it does not exist.

So the question arises: where does this function come from, and how does it come into that list? The second question is easier to answer than the first: it comes with the “registration” step above: the initialization function, that is registered for every plugin, actually adds these functions - OR NOT!

In my specific case I found out that those plugins that did load properly did have such an initialization function (_Init()), but that was empty. Not that the “new instance functions” (ClientServerNewCommand) did not exist for the class - only they were not added withing the Init function!

This adding of that function into the _Init() function seems to be named “client server wrapping” in the PV language. But where does it happen? There is actually an external tool for that purpose: vtkWrapClientServer.

Now this program takes a “hierarchy” file as input, and somehow processes this into the proper “wrapping” code in the _Init() function - or else just generates an empty dummy. So next question: what is this “hierarchy” file and where does it come from? Looking into it, it looks like it contains some info about required code for the working of a specific class, like the parent class and somehow also many others.

This I also did not fully get detangled, but I was lucky that my guess went now towards the vtk.module vile - which has both a DEPENDS and a PRIVATE_DEPENDS section - and that looks like where the key for the “strange” behaviour can be found:

  • If nothing is in the DEPENDS section, the cmake code will already complain that this is not very likely - because whatever module is there, must depend on something.
  • Next you will get compile errors if certain #includes are not found. In my case, with all code that was already once built and tested successfully with an earlier version of PV, this always meant: some additional target/module/library has to be added in the vtk.module file.

With this, the entire application finally built and started successfully! But - see above.

Now so far I put some of the dependencies into the DEPENDS section - if I had the impression that they are “core” for that new module - and others I put into the PRIVATE_DEPENDS section, like if the module is only “using” some functions from another module. And for compilation it looks like there is no really visible difference between the two. So I put more into the PRIVATE_DEPENDS - like I would also put all “internal” stuff into the private section of a C++ class. But that turned out to be completely wrong:

THE DIFFERENCE IS WITH THE “CLIENT SERVER WRAPPING”!!

So finally the “trick” was: move some more modules/targets from the PRIVATE_DEPENDS to the DEPENDS section. The effect was: the “hierarchy” files became much bigger - and finally the “new instance functions” were also appearing in the _Init() functions - AND THE PLUGINS DID NOT CRASH ANY MORE!

I am writing this long story only in order to help others to avoid this very long and tedious way: Of course I left out all the many detours that I also had to try unsuccessfully. So I am now happy if I can save one person from having to repeat this odyssee!

1 Like

Thanks @cobo

To summarize, in your vtk.module, make sure to expose all modules they need to be wrapped in the DEPENDS category. PRIVATE_DEPENDS are only for fully internal dependencies and or completely invisible from other modules or from ParaView.

Hello (again today is ParaView day for me :wink: )

I have some troubles porting my PV 5.5 plugin into PV 5.7. And it is related more or less to this discussion. I’ve encountered the same troubles as described by @cobo, but for a different reason I think.

I first tried to move things from the DEPENDS_PRIVATE to DEPENDS sections without success.
In fact, my plugin code is written with coding rules I have on my overall project. That mean that

  • my include files are separated from my sources in /include and /src subdirs in my project.
  • my C++ sources have the ‘.cpp’ extension and not ‘.cxx’
  • the sources and includes are sorted into subfolders to classify them by functionnalities
  • (and I like this organization, it is clear to me !)

So I tried to build my VTK module (on which my PV Plugin depends) with the following code:
VTK_MODULE_ADD_MODULE( ${PROJECT_NAME} SOURCES "${PV_PLUGIN_SOURCES}" )
PV_PLUGIN_SOURCES containing the sources exhaustive list with full path.

With this, my classes are not wrapped by the VTK tool and I get into the error described above (my Init() function in the module being empty).

So I tried to stick to the documentation example and put (very draftly, for the test) all includes and sources into the module folder, and renamed .cpp into .cxx then I used:
SET( VTK_FILTERS_CLASSES **a very large bunch of classes list!** ) VTK_MODULE_ADD_MODULE( ${PROJECT_NAME} CLASSES "${VTK_FILTERS_CLASSES}" )
And that worked…

Meaning that we MUST stick to the VTK way of coding to develop a plugin ? It is a bit too constraining I think…

So , is there any mean to keep my code organization and build my plugin for ParaView ?

Thanks in advance,
Yves

Then I can reply to myself : just forgetting to separate SOURCES and HEADERS. I figured this out by reading the VTK_MODULE_ADD_MODULE() code : the wrapping is done, based on the headers list.

Then, my bad, all this work perfectly with any kind of sources organization.
I just have now to reorganize properly the cmake procedures the good way…

Thanks if anyone spent some time on this question :slight_smile:

1 Like

That means the wrapper failed to find any candidate classes. I suppose we could add a reason to the file as a comment or something. (Cc @dgobbi for how feasible that would be)

Do you have output for this? EXCLUDE_WRAP will also exclude ClientServer (since that is a wrapping “language”). The hierarchy files are necessary for all wrappers.

For the XML errors, I’m not sure; the XML stuff isn’t my strong suit. @utkarsh.ayachit?

For modules not under plugins, did you call vtk_module_wrap_client_server?

It’s still very important. Are you thinking of //BTX and friends?

It might be anemic, but what is inaccurate about it?

  * `EXCLUDE_WRAP`: If present, this module should not be wrapped in any
    language. 

Each language sets their own __VTK_WRAP__ preprocessor definition. So you can do one of:

  • not pass the module to vtk_module_wrap_python
  • “hide” classes from Python using __VTK_WRAP_PYTHON__

This is also possible with PRIVATE_CLASSES which is SOURCES and PRIVATE_HEADERS.

That is a bug. Can you share the full file? As for the cxx extension, yes. One of the VTK assumptions that leaked through…

The convenience bits are VTK-specific (e.g., cxx extension assumptions), but it should be possible to use any code layout within a module.

Don’t quote it. That gets seen as a single class name, not a list. Or at least it probably is. Something might still double-list-expand or something, but for this, quoting should not be used (my rule: if it is a list of arguments, don’t quote, otherwise quote all expansions that you can).

Thanks all @coro @Artem_Bodrin @rogezy for your input here; I’ll use it when working on the documentation of the build system for VTK 9.0 and ParaView 5.8.

Thanks, @ben.boeckel, for your interest to this topic.

Well, I’m a side developer, and “language” term for me here is any supported programming language, like python, java, etc. Now I know, that you include *ClientServer.cxx - generated files to this term also. Sounds a bit unusual, but ok. Maybe better to extend the description? Something like this:

  • EXCLUDE_WRAP: If present, this module should not be wrapped in any
    language (also excludes generation of client-server communication source files).

I tried to reproduce that bug. AFAIR I had in on RC3. I do not remember, if it was exactly this, but here what I’ve got.
For speed I’ve just changed ParaViewCore/Core/CMakeLists.txt like in attached file CMakeLists.txt (2.0 KB) , and got this on cmake configuration step:

CMake Error at /Volumes/SSD-T5/devel/specifx/specifx/VTK/CMake/vtkModule.cmake:2843 (message):
Unparsed arguments for vtk_module_add_module:
PRIVATE_SOURCES;vtkPVXMLElement.cxx
Call Stack (most recent call first):
/Volumes/SSD-T5/devel/specifx/specifx/ParaViewCore/Core/CMakeLists.txt:58 (vtk_module_add_module)
– Configuring incomplete, errors occurred!

Please, take a note, that documentation on vtk_module_add_module does not forbid that anyhow. When I got that bug, I was to create my tiny module…

UPDATE:
VTK/CMake/vtkModule.cmake:2886

if (NOT _vtk_add_module_SOURCES AND NOT _vtk_add_module_HEADER_ONLY)
message(WARNING
“The ${_vtk_build_module} module has no source files.”)
endif ()

That’s the kind of message I’ve got back then. But it’s a warning, so I guess the error was somewhere else. Still, I’ve found another error :point_up_2:

My bad. That was what I had in mind. I’ve edited my message so nobody get confused.

Ah, that is a bug. I think I documented it in one way, but then realized that SOURCES == PRIVATE_SOURCES in every way during the implementaiton (since there’s no such thing as a public source right now) and never went back to fix the docs. I’ll update the docs. Sorry for the confusion.

MR for the fix: https://gitlab.kitware.com/vtk/vtk/merge_requests/6098