Again - "client server wrapping" - any fool proof instructions about how to ensure it is "properly initialized"?

Of course the code is again a bit more complicated than in the basic examples - and the result is the famous message about “…client server wrapping probably not properly initialized”.

And yes I see: the *ClientServer.cxx file is just the dummy: an empty *_Init(…) function, while the other, slightly differently built plugin has in that same file a lot of code.

And again I am since hours trying to detangle the cmake/C++/… spaghetti code of this module building process in order to find out what and where something could be wrong…

There is also a *.hierarchy.depends.args file that looks like it might need some additional content: It is only this:

"C:/dev/pv580/rel/lib/vtk/hierarchy/ParaView/vtkFiltersCore-hierarchy.txt"
"C:/dev/pv580/rel/lib/vtk/hierarchy/ParaView/vtkCommonCore-hierarchy.txt"

but in the vtk.module there is one more DEPENDS line:

NAME
  AthosGeoBlend::AtgBlendSamplingReaderModule
LIBRARY_NAME
  AtgBlendSamplingReaderModule
DEPENDS
  AthosGeoView::AtgFilters
  VTK::FiltersCore
  VTK::CommonCore
PRIVATE_DEPENDS
  AthosGeoView::AtgUtilities
  ParaView::pqComponents

Actually the “AthosGeoBlend” project depends on “AthosGeoView” which in turn depends on ParaView.

And there would indeed also be another *-hierarchy.text file available that might have to end up in the *-hierarchy.depends.args file:

C:/dev/atgview/rel/lib/hierarchy/AthosGeoView/AtgFilters-hierarchy.txt

But how can I bring this line into the *-hierarchy.depends.args file?

However, it is just a guess that it might belong there: Maybe there are some completely different things missing in the setup??

So for this reason I would be happy if I could follow some systematic path for finding out - not only the fact that “client server wrapping is missing”, but how to make it happen?

This usually means that AthosGeoView::AtgFilters is missing wrapping itself. Since it is a different namespace, I presume it is found via find_package() (given later information), Is that package including the ${package}-vtk-module-properties.cmake file in its config.cmake? I don’t know how we can verify that it is included, but I guess docs on making config.cmake files for VTK-module-containing projects is probably in order.

Ok, thanks for these hints: It somehow confirms that probably something is wrong with the way how the AthosGeoBlend project “inherits” features from the AthosGeoView project! And indeed it is most likely not really how it should be - simply because I never fully understood how to properly organize such an interface.

I had to separate these two projects because of licensing issues, but many of the AGView features are imported in a rather “hackish” way. I learned a lot about this CMake terminology of “install”, “import”, “export” etc., but I must admit that a lot is still missing!

In short: Yes, AthosGeoView::AtgFilters seems to be properly “wrapped”, since inside the AthosGeoView project there is a plugin that successfully uses it, and there is also a AtgFilters-hierarchy.txt file that contains some “hierarchy info” inside the AthosGeoView project directory tree that looks “reasonably full”. But there is neither any config.cmake file nor any …-vtk-module-properties.cmake file, and the “import” is also not working with find_package(). So if these mechanisms are supposed to be the solution of the problem, then I know now where the problem is actually not solved!

In other words: to me it looks like there is proper wrapping of that module, but this wrapping info is not properly exported and imported - and this is exactly the field where I still have most troubles with understanding the CMake concepts (together with the meaning of “install” which looks like I still only understand it partially). I learned a lot during the endless porting activity from PV5.6 to 5.7 - and ended up with some solution that “somehow works” but is definitely not really how it should be.

Looks like I have now two options:

  • either try to still better understand how this project install/export/import “magic” with find_package etc. is working and try to implement it properly
  • or a quick and dirty solution: Instead of a class inheritance A inherits from B inherits from C I change it to being A inherits from C, “clones” the interface of B and simply uses that class. In this case B does not appear in the “hierarchy” and I might get things to work quickly.

The first solution would be good for the clean project setup and maybe further developments, while the second would possibly bring me more quickly now to a working solution…

44min since my previous posting, and the “quick and dirty” solution is running just fine!

Still - maybe I should eventually do another effort to better understand the many install/import/export miracles! Not that I understand nothing now, but obviously it is not enough yet :wink:

It sounds like you have the bits installing properly, but there’s something missing from the find_package(AthosGeoView) logic. There’s an AthosGeoViewConfig.cmake (or -config.cmake) file somewhere. That file needs to end up including the *-vtk-module-properties.cmake file(s) that should be beside it. If they’re not beside it, something is telling the module system that development files aren’t wanted, so it doesn’t install them.

Thanks - I will have another look into this!