### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [November 6, 2024, 8:34am UTC](https://discourse.paraview.org/t/strange-cmake-problem-when-porting-from-pv-5-12-0-to-pv-5-13-1/15687/2 "2024-11-06T08:34:00Z")
Could you share the precise error you are getting ?
---
### Author:  [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [November 6, 2024, 9:41am UTC](https://discourse.paraview.org/t/strange-cmake-problem-when-porting-from-pv-5-12-0-to-pv-5-13-1/15687/3 "2024-11-06T09:41:13Z")
Right - I just wanted to share some log output when I saw your reply!
The following is some log output that was generated with the PV 5.12.0 version (which so far I kept for the Release variant). You see a lot of stuff that I added inside different .cmake codes using the message() function for tracking.
On top of that I activated the “verbose” option in cmake-gui which generated the “Entering…” and “Returning…” message that seem to be produced by the `add_subdirectory` function.
The %%% messages were written immediately before (1) and after (2) calling `add_subdirectory`. During that call, `AthosGeoView::AtgDomainsModule` is defined as a TARGET (which it is not before), with a `headers` property that is a list of 6 header files including their full path which are listed in the \*\*\* cs\_header messages. From this are later derived “client\_server\_sources” and then “client\_server\_classes”:
> Entering /home/cornelis/Main/develop/AthosGeo/Projects/View/Sources/Plugins/AtgDomains
> ===\*\*\* going to vtk\_module\_build AthosGeoView::AtgDomainsModule
> %%%\*\*\* (1) inside vtk\_module\_build for AthosGeoView::AtgDomainsModule
> %%% module AthosGeoView::AtgDomainsModule not defined yet as a TARGET
> %%% adding src dir \
> %%% adding bin dir \
> Entering /home/cornelis/Main/develop/AthosGeo/Projects/View/Sources/Plugins/AtgDomains/AtgDomainsModule
> Returning to /home/cornelis/Main/develop/AthosGeo/Projects/View/Sources/Plugins/AtgDomains
> %%%\*\*\* (2) inside vtk\_module\_build for AthosGeoView::AtgDomainsModule
> %%% module AthosGeoView::AtgDomainsModule has 6 headers
> ===\*\*\* done vtk\_module\_build AthosGeoView::AtgDomainsModule
> == module AthosGeoView::AtgDomainsModule has 6 headers
> ===\*\*\* going to vtk\_module\_wrap\_client\_server AthosGeoView::AtgDomainsModule
> == module AthosGeoView::AtgDomainsModule has 6 headers
> \*\*\*+++ vtk\_module\_wrap\_client\_server
> \*\*\* cs\_modules AthosGeoView::AtgDomainsModule
> \*\*\*+++ \_vtk\_module\_wrap\_client\_server\_library
> \*\*\*+++ \_vtk\_module\_wrap\_client\_server\_sources
> \*\*\* module AthosGeoView::AtgDomainsModule
> \*\*\* cs\_headers length 6
> \*\*\* cs\_header \
> \*\*\* cs\_header \
> \*\*\* cs\_header \
> \*\*\* cs\_header \
> \*\*\* cs\_header \
> \*\*\* cs\_header \
> \*\*\* cs\_sources length 6
> \*\*\* cs\_classes length 6
> ===\*\*\* done vtk\_module\_wrap\_client\_server AthosGeoView::AtgDomainsModule
> Returning to /home/cornelis/Main/develop/AthosGeo/Projects/View/Sources
You can see that it finds 5 header files in the “source directory” and one in the “binary directory”.
Now the exactly same thing with PV 5.13.1 for the Debug build of the same code:
> Entering /home/cornelis/Main/develop/AthosGeo/Projects/View/Sources/Plugins/AtgDomains
> \*\*\*+++ paraview\_add\_plugin
> ===\*\*\* going to vtk\_module\_build AthosGeoView::AtgDomainsModule
> %%%\*\*\* (1) inside vtk\_module\_build for AthosGeoView::AtgDomainsModule
> %%% module AthosGeoView::AtgDomainsModule not defined yet as a TARGET
> %%% adding src dir \
> %%% adding bin dir \
> Entering /home/cornelis/Main/develop/AthosGeo/Projects/View/Sources/Plugins/AtgDomains/AtgDomainsModule
> Returning to /home/cornelis/Main/develop/AthosGeo/Projects/View/Sources/Plugins/AtgDomains
> %%%\*\*\* (2) inside vtk\_module\_build for AthosGeoView::AtgDomainsModule
> %%% module AthosGeoView::AtgDomainsModule has 5 headers
> ===\*\*\* done vtk\_module\_build AthosGeoView::AtgDomainsModule
> == module AthosGeoView::AtgDomainsModule has 5 headers
> ===\*\*\* going to vtk\_module\_wrap\_client\_server AthosGeoView::AtgDomainsModule
> == module AthosGeoView::AtgDomainsModule has 5 headers
> \*\*\*+++ vtk\_module\_wrap\_client\_server
> \*\*\* cs\_modules AthosGeoView::AtgDomainsModule
> \*\*\*+++ \_vtk\_module\_wrap\_client\_server\_library
> \*\*\*+++ \_vtk\_module\_wrap\_client\_server\_sources
> \*\*\* module AthosGeoView::AtgDomainsModule
> \*\*\* cs\_headers length 5
> \*\*\* cs\_header \
> \*\*\* cs\_header \
> \*\*\* cs\_header \
> \*\*\* cs\_header \
> \*\*\* cs\_header \
> \*\*\* cs\_sources length 5
> \*\*\* cs\_classes length 5
> ===\*\*\* done vtk\_module\_wrap\_client\_server AthosGeoView::AtgDomainsModule
> Returning to /home/cornelis/Main/develop/AthosGeo/Projects/View/Sources
This module seems to be “accepted” so far, but already here the result is not exactly the same as with the PV 5.12.1 version: The header file in the binary directory is not added, so the total number is only 5 headers found and not 6. And reading the reference for the `add_subdirectory` function, it should not scan that binary directory - as far as I understand.
The following is the `CMakeLists.txt` file that `add_subdirectory` finds in both cases in that subdirectory (source directory):
> set(classes
> vtkSMCategoryArraysDomain
> vtkSMPitArraysDomain
> vtkSMRenameableArraysDomain
> vtkSMTonnageArraysDomain
> vtkSMCellIdArraysDomain)
>
> vtk\_module\_add\_module(AthosGeoView::AtgDomainsModule
> CLASSES
> ${classes})
>
> # the only purpose of this is to bring the vtk.module file into QtCreator
> add\_custom\_target(AtgDomains\_module\_spec
> SOURCES ${CMAKE\_CURRENT\_SOURCE\_DIR}/vtk.module)
Now the log from the PV 5.13.1 version of the next module that finally terminates with error message (while with PV 5.12.0 it succeeds - with 1 header found in the binary directory and none in the source directory - which is correct):
> Entering /home/cornelis/Main/develop/AthosGeo/Projects/View/Sources/Plugins/AtgPropertyWidgets
> \*\*\*+++ paraview\_add\_plugin
> ===\*\*\* going to vtk\_module\_build AthosGeoView::AtgPropertyWidgetsModule
> %%%\*\*\* (1) inside vtk\_module\_build for AthosGeoView::AtgPropertyWidgetsModule
> %%% module AthosGeoView::AtgPropertyWidgetsModule not defined yet as a TARGET
> %%% adding src dir \
> %%% adding bin dir \
> Entering /home/cornelis/Main/develop/AthosGeo/Projects/View/Sources/Plugins/AtgPropertyWidgets/AtgPropertyWidgetsModule
> Returning to /home/cornelis/Main/develop/AthosGeo/Projects/View/Sources/Plugins/AtgPropertyWidgets
> %%%\*\*\* (2) inside vtk\_module\_build for AthosGeoView::AtgPropertyWidgetsModule
> %%% module AthosGeoView::AtgPropertyWidgetsModule has 0 headers
> ===\*\*\* done vtk\_module\_build AthosGeoView::AtgPropertyWidgetsModule
> == module AthosGeoView::AtgPropertyWidgetsModule has 0 headers
> ===\*\*\* going to vtk\_module\_wrap\_client\_server AthosGeoView::AtgPropertyWidgetsModule
> == module AthosGeoView::AtgPropertyWidgetsModule has 0 headers
> \*\*\*+++ vtk\_module\_wrap\_client\_server
> \*\*\* cs\_modules AthosGeoView::AtgPropertyWidgetsModule
> \*\*\*+++ \_vtk\_module\_wrap\_client\_server\_library
> \*\*\*+++ \_vtk\_module\_wrap\_client\_server\_sources
> \*\*\* module AthosGeoView::AtgPropertyWidgetsModule
> \*\*\* cs\_headers length 0
> \*\*\* cs\_sources length 0
> \*\*\* cs\_classes length 0
> \*\*\* \ is NOT a TARGET
> CMake Error at /home/cornelis/Main/develop/ParaView/Binaries/ParaView-v5.13.1/Debug/lib/cmake/paraview-5.13/vtkModuleWrapClientServer.cmake:433 (message):
> No modules given could be wrapped.
> Call Stack (most recent call first):
> /home/cornelis/Main/develop/ParaView/Binaries/ParaView-v5.13.1/Debug/lib/cmake/paraview-5.13/ParaViewPlugin.cmake:1284 (vtk\_module\_wrap\_client\_server)
> Plugins/AtgPropertyWidgets/CMakeLists.txt:123 (paraview\_add\_plugin)
>
> Returning to /home/cornelis/Main/develop/AthosGeo/Projects/View/Sources
> Configuring incomplete, errors occurred!
And that’s it then for the build based on PV 5.13.1! The `CMakeLists.txt` file in that second subdirectory is this (all about Qt widgets for the properties panel). Indentation seems to get lost with the “blockquote”:
> set(interfaces)
> set(sources)
>
> paraview\_plugin\_add\_property\_widget(
> KIND
> WIDGET\_DECORATOR
> TYPE
> “ShowOnlyIfNewAttribute”
> CLASS\_NAME
> atgShowOnlyIfNewAttribute
> INTERFACES
> property\_interfaces
> SOURCES
> property\_sources)
>
> list(APPEND interfaces
> ${property\_interfaces})
> list(APPEND sources
> ${property\_sources})
>
> paraview\_plugin\_add\_property\_widget(
> KIND
> GROUP\_WIDGET
> TYPE
> “BlockModelParam”
> CLASS\_NAME
> widBlockModelParam
> INTERFACES
> property\_interfaces
> SOURCES
> property\_sources)
>
> list(APPEND interfaces
> ${property\_interfaces})
> list(APPEND sources
> ${property\_sources})
>
> paraview\_plugin\_add\_property\_widget(
> KIND
> GROUP\_WIDGET
> TYPE
> “CategoryValue”
> CLASS\_NAME
> widCategoryValue
> INTERFACES
> property\_interfaces
> SOURCES
> property\_sources)
>
> list(APPEND interfaces
> ${property\_interfaces})
> list(APPEND sources
> ${property\_sources})
>
> paraview\_plugin\_add\_property\_widget(
> KIND
> WIDGET
> TYPE
> “CellArrays”
> CLASS\_NAME
> widCellArrays
> INTERFACES
> property\_interfaces
> SOURCES
> property\_sources)
>
> list(APPEND interfaces
> ${property\_interfaces})
> list(APPEND sources
> ${property\_sources})
>
> paraview\_plugin\_add\_property\_widget(
> KIND
> GROUP\_WIDGET
> TYPE
> “MultiSelsAndValues”
> CLASS\_NAME
> widMultiSelsAndValues
> INTERFACES
> property\_interfaces
> SOURCES
> property\_sources)
>
> list(APPEND interfaces
> ${property\_interfaces})
> list(APPEND sources
> ${property\_sources})
>
> paraview\_plugin\_add\_property\_widget(
> KIND
> GROUP\_WIDGET
> TYPE
> “SamplingParam”
> CLASS\_NAME
> widSamplingParam
> INTERFACES
> property\_interfaces
> SOURCES
> property\_sources)
>
> list(APPEND interfaces
> ${property\_interfaces})
> list(APPEND sources
> ${property\_sources})
>
> paraview\_plugin\_add\_property\_widget(
> KIND
> GROUP\_WIDGET
> TYPE
> “SelectionIds”
> CLASS\_NAME
> widSelectionIds
> INTERFACES
> property\_interfaces
> SOURCES
> property\_sources)
>
> list(APPEND interfaces
> ${property\_interfaces})
> list(APPEND sources
> ${property\_sources})
>
> paraview\_add\_plugin(AtgPropertyWidgets
> VERSION
> “1.0.0”
> SOURCES
> ${sources}
> UI\_INTERFACES
> ${interfaces}
> MODULES
> AthosGeoView::AtgPropertyWidgetsModule
> MODULE\_FILES
> AtgPropertyWidgetsModule/vtk.module
> MODULE\_ARGS
> INSTALL\_EXPORT AthosGeoView)
>
> # the only purpose of this is to bring the vtk.module file into QtCreator
> add\_custom\_target(AtgPropertyWidgets\_plugin\_spec
> SOURCES ${CMAKE\_CURRENT\_SOURCE\_DIR}/paraview.plugin)
The reason why I brought both module examples is the fact that even though only the second fails, also the first shows the same “effect”, so it looks like it is really not coming from the fact that this module is all widgets, with auto-generated (“moc’ed”) code etc.
I have now downloaded the entire source code of CMake, in order to find out what may be going on inside the `add_subdirectory` function that in one case finds a header file that in the other it does not find. Because that header file _does_ exist also in the second (PV 5.13.1) variant!
---
### Author:  [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [November 6, 2024, 5:18pm UTC](https://discourse.paraview.org/t/strange-cmake-problem-when-porting-from-pv-5-12-0-to-pv-5-13-1/15687/4 "2024-11-06T17:18:01Z")
Looks like diving into the code of `add_subdirectory` does not deliver much helpful insight: it simply reads the `CMakeLists.txt` in that subdirectory and executes the commands that are there. Which is for example:
> vtk\_module\_add\_module(AthosGeoView::AtgDomainsModule
> CLASSES
> ${classes})
Analyzing now this function shows some code where `CLASSES` are actually treated as if they were `SOURCES` plus `HEADERS`. But then - surprise! - another list enters the game that is obviously not part of the above function call: `NOWRAP_HEADERS`, and this contains then that single header file residing in the binary directory. It appears with full path, while the other headers are just filenames.
Next questions are: a) Where is this `NOWRAP_HEADERS` coming from? And b) why is it getting lost in one of the two variants?
Answer a) seems to lie in the following piece of code in `vtkModule.cmake`:
> if (NOT \_vtk\_add\_module\_HEADER\_ONLY AND NOT \_vtk\_add\_module\_third\_party)
> set(\_vtk\_add\_module\_generated\_header
> “${CMAKE\_CURRENT\_BINARY\_DIR}/${\_vtk\_add\_module\_module\_header\_name}”)
> list(APPEND \_vtk\_add\_module\_NOWRAP\_HEADERS
> “${\_vtk\_add\_module\_generated\_header}”)
> endif ()
So there it is: the “magic” that brings the binary directory into the game!
Question b) will be for tomorrow…
PS: If you have CMake, you really do not need detective stories any more 🙂
---
### Author:  [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [November 7, 2024, 10:38am UTC](https://discourse.paraview.org/t/strange-cmake-problem-when-porting-from-pv-5-12-0-to-pv-5-13-1/15687/5 "2024-11-07T10:38:27Z")
It looks like I have found the bug - and it is within `vtkModule.cmake` in PV 5.13.1:
> set(\_vtk\_add\_module\_module\_header\_name
> “${\_vtk\_add\_module\_library\_name}Module.h”)
> if (NOT \_vtk\_add\_module\_HEADER\_ONLY AND NOT \_vtk\_add\_module\_third\_party)
> set(\_vtk\_add\_module\_generated\_header
> “${CMAKE\_CURRENT\_BINARY\_DIR}/${\_vtk\_add\_module\_module\_header\_name}”)
> list(APPEND \_vtk\_add\_module\_NOWRAP\_HEADERS
> “\<${\_vtk\_add\_module\_generated\_header}”)
> endif ()
In PV 5.12.0 this looks _slightly_ different:
> set(\_vtk\_add\_module\_module\_header\_name
> “${\_vtk\_add\_module\_library\_name}Module.h”)
> if (NOT \_vtk\_add\_module\_HEADER\_ONLY AND NOT \_vtk\_add\_module\_third\_party)
> set(\_vtk\_add\_module\_generated\_header
> “${CMAKE\_CURRENT\_BINARY\_DIR}/${\_vtk\_add\_module\_module\_header\_name}”)
> list(APPEND \_vtk\_add\_module\_HEADERS
> “${\_vtk\_add\_module\_generated\_header}”)
> endif ()
The difference is: in the new version, the “module module header” is appended to the NOWRAP\_HEADERS, which has the effect that it is not added to the headers of the module target - which leads after several intermediate steps to the effect that I observed: This header is always missing from the headers list of that module!
However, now it remains to find the location where this change has to be applied in the sources of PV 5.13.1 (because `vtkModule.cmake` is in the binary tree of the PV build), and finally try if my problem goes indeed away with that change…
Some more explanation: In the following piece of code the actual “attaching” of the headers to the target is happening (in some miraculous way):
> set\_property(TARGET “${\_vtk\_add\_module\_real\_target}”
> PROPERTY
> “INTERFACE\_vtk\_module\_headers” “${\_vtk\_add\_module\_headers\_build}”)
Immediately before that code, all the list members of `_vtk_add_module_HEADERS` get their full path prepended, resulting in the list `_vtk_add_module_headers_build`. However, the list `_vtk_add_module_NOWRAP_HEADERS` is for the garbage, never ever touched again, and so this “module module header” gets lost (and the above code that appends it to that list has no effect at all).
---
### Author:  [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [November 8, 2024, 11:13am UTC](https://discourse.paraview.org/t/strange-cmake-problem-when-porting-from-pv-5-12-0-to-pv-5-13-1/15687/6 "2024-11-08T11:13:13Z")
Bottom line:
- With the above fix in `vtkModule.cmake`, my custom ParaView application builds again successfully (with some little adaptations that still need to ensure full compatibility with the new version)
- I my eyes it is clear that it is a bug in that `vtkModule.cmake` file and my change is a fix and not just a patch that somehow “saves” a wrong setup in my own project. The strongest indication for this is for me the fact that the wrong statement updates a variable that is afterwards never ever being used, thus just for the garbage
---
### Author:  [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [November 10, 2024, 4:05pm UTC](https://discourse.paraview.org/t/strange-cmake-problem-when-porting-from-pv-5-12-0-to-pv-5-13-1/15687/7 "2024-11-10T16:05:32Z")
Bad news: At first it looked like the problem is solved, but now it turns out that some more deeper lying problems are present with this version 5.13.1 that I could not really investigate yet.
Yes, the project builds now correctly, and it is possible to start it. But once a plugin needs to be loaded that provides a number of property widgets, Linux terminates with a message that tells me that the required constructor cannot be found in the plugin file:
```auto
/home/cornelis/Main/develop/AthosGeo/Projects/Blend/Binaries23/Debug/bin/AthosGeoBlend: symbol lookup error: /home/cornelis/Main/develop/AthosGeo/Projects/Blend/Binaries23/Debug/bin/AtgPropertyWidgets.so: undefined symbol: _ZN16widCategoryValueC1EP10vtkSMProxyP18vtkSMPropertyGroupP7QWidget
```
Using `nm` shows that the demangled name of this symbol actually is `widCategoryValue::widCategoryValue(vtkSMProxy*, vtkSMPropertyGroup*, QWidget*)`, and using again `nm` on the .so file shows that this symbol is somehow there, but of type `U` - meaning “undefined”. From the fact that in that row there is no entry address I conclude that “undefined” means in this case: the symbol is “defined”, but it points to no binary code or data or whatever.
Bottom line: It looks like there is still more broken in that `vtkModule.cmake"` than what I have already found - and lacking that kind of “low level” know-how regarding linking etc., I am afraid that even more digging and diving might be the result of this finding.
---
### Author:  [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [November 11, 2024, 7:25am UTC](https://discourse.paraview.org/t/strange-cmake-problem-when-porting-from-pv-5-12-0-to-pv-5-13-1/15687/9 "2024-11-11T07:25:21Z")
Next finding: Also in an older, correctly working version of the software the symbols of the widget classes are marked as “U”. However, the plugin has a corresponding .so file that seems to define the “module”: `libAtgPropertyWidgetsModule.so`, and here the symbols for the actual widgets are defined in the old version, but not in the current one.
From which I conclude that the “undefined” symbols in the plugin library are kind of placeholders for the implementations in the module library.
Interestingly, also in the module library the widget class symbols are visible, but again as “U” without code, while in the older version they are there in a “T” section - meaning: there is some real code.
Bottom line: The question is why the actual code does not make it into the module library, and my current guess is that the many little changes in `vtkModule.cmake` might be somehow related, but this is so far only a vague guess…
First I would need to understand how the module code is actually supposed to find it’s way into the module library, and then I will have to see where exactly it does not happen any more in the current CMake setup.
---
### Author:  [@cobo](https://discourse.paraview.org/u/cobo)
#### Post date: [November 11, 2024, 1:53pm UTC](https://discourse.paraview.org/t/strange-cmake-problem-when-porting-from-pv-5-12-0-to-pv-5-13-1/15687/10 "2024-11-11T13:53:49Z")
Looks like a solution was found - in still another direction than what I initially guessed.
During my internet research also regarding “wrapping”, I came to a 5 years old problem that I had completely forgotten, but at the time it was myself who initiated it: [How to ensure that "client-server wrapping is properly initialized"?](https://discourse.paraview.org/t/how-to-ensure-that-client-server-wrapping-is-properly-initialized/2556). So it was partially my own explanations in that thread that brought me back on track also this time! So again I am going to explain the two problems together with their current solutions.
1. This is the problem that I solved by undoing a little change in `vtkModule.cmake`, which caused CMake to terminate early due to no headers found for a plugin. This could be solved by simply undoing a change that Ben Boeckel has made about one year ago: [https://gitlab.kitware.com/vtk/vtk/-/commit/cf774eac9efcad39ae0893c2fbcfcac561e43abb](https://gitlab.kitware.com/vtk/vtk/-/commit/cf774eac9efcad39ae0893c2fbcfcac561e43abb). From his comment (“There’s nothing wrappable here anyways.”) I conclude that there was no “urgent need” for this step, but simply it looked more logical like that. Which may be true, but I cannot judge this. However, in my case this triggered a side effect in the case of a plugin that had no other headers left then, and via some other steps the `vtkModuleWrapClientserver.cmake` terminated with the message that I had initially: `No modules given could be wrapped`. I saw that also for all the other plugins one less header was attached, but whether this would have caused any trouble or not I cannot judge because at the end I could not build anything because of this error!
2. That same plugin was also in the core of the second problem: Start the successfully built application, generate a “block model” with some specific “source” within my application (…from which I conclude that “regular” plugins with “filters” do actually build AND run…), but on pressing “Apply”, the program crashed with the message that I cited above: symbol not found. Which was the constructor of a property widget class which should have been generated in the “Display” panel. Meaning: a plugin with only property widget code and no “filter” was not correctly built.
It turned out that it was exactly the same plugin that caused already the trouble 5 years ago: the `vtkWrapHierarchy` seems to be unable to parse headers that refer to Qt widgets, always complaining about “syntax errors” that are not really there, with no way to change the code in such a way that the tool is happy and still also the C++ compiler.
At the time (5 years ago) it turned out that the key lies in the `CMakeLists.txt` file for the module code to be embedded in the plugin. This was the initially intended way of writing it in that file (with parts omitted that are irrelevant for the problem):
```auto
set(classes
widBlockModelParam
widCategoryValue
widCellArrays
widMultiSelsAndValues
widSamplingParam
widSelectionIds
vtk_module_add_module(AthosGeoView::AtgPropertyWidgetsModule
CLASSES
${classes}
SOURCES
...
```
But this is is exactly what caused the trouble at that time. The solution was then finally:
```auto
set(classes
widBlockModelParam
widCategoryValue
widCellArrays
widMultiSelsAndValues
widSamplingParam
widSelectionIds
vtk_module_add_module(AthosGeoView::AtgPropertyWidgetsModule
SOURCES
${classes}
${ui_files}
${qrc_files}
...
```
This worked at the time, but obviously not any more with the current PV version 5.13.1! I saw now that “strange” code, having completely forgotten the reason for it (lack of good commenting…), so I changed it back: I was getting again the error messages from the `vtkWrapHierarchy` tool that “hates” Qt widget headers. (And after an internet search I hit that old “discourse” thread…)
From this I knew that it is all about the headers, while the sources are required to generate some code at all. The format with class names being passed as `SOURCES` probably has the effect that for each class, both a .cxx and a .h are added - and as long as the .h files were not added in a `HEADERS` section (which would be the effect of putting that same list into a `CLASSES` section), everything went fine with PV 5.12.0.
But not with 5.13.1! However, changing the above to the following at least generated code that did not crash any more:
```auto
set(sources
widBlockModelParam.cxx
widCategoryValue.cxx
widCellArrays.cxx
widMultiSelsAndValues.cxx
widSamplingParam.cxx
widSelectionIds.cxx)
vtk_module_add_module(AthosGeoView::AtgPropertyWidgetsModule
SOURCES
${sources}
${ui_files}
${qrc_files}
...
```
Only one little problem remained: The headers disappeared now also from the `QtCreator` display! But finally with the following also this could be solved:
```auto
set(sources
widBlockModelParam.cxx
widCategoryValue.cxx
widCellArrays.cxx
widMultiSelsAndValues.cxx
widSamplingParam.cxx
widSelectionIds.cxx)
set(private_headers
atgShowOnlyIfNewAttribute.h
widBlockModelParam.h
widCategoryValue.h
widCellArrays.h
widMultiSelsAndValues.h
widSamplingParam.h
widSelectionIds.h)
vtk_module_add_module(AthosGeoView::AtgPropertyWidgetsModule
SOURCES
${sources}
${ui_files}
${qrc_files}
PRIVATE_HEADERS
${private_headers}
...
```
So basically in some way these widget classes are now “half private” 😄
Now I learned that I will have to write good comments into my code - and go on testing…
What I know now is the fact that my plugin with property widgets needs “wrapping” only in order to be somehow considered a “proper plugin” that can be loaded and used from other plugins and code. For any decent technical reason, “wrapping” would not be required at all, because these widgets only appear on the client, not on the server side of the application.
And even though it may be true basically what Ben Boeckel is writing: “nothing wrappable there…”, plus the fact that the entire thing also does not need any “wrapping”, changing his code line back to the “unlogical” form that was there before is for me currently the only way to “make it happen” again.
If anybody now can point me to some example or tutorial that tells me how to achieve that without “funny workarounds” I would probably simplify my code accordingly. If not, I am for the moment glad I found some solutions that works “somehow”.