At my company, we are upgrading our custom application based on ParaView 5.9. to 5.10.1. I was able to successfully build it.
I started to update our “superbuild” (Paraview-super build fork) but I am having some weird compilation issues. It’s related to the new define VTK_FILEPATH
I get the following error :
cd /builds/superbuild/superbuild/paraview/build/VTK/Common/Core && /builds/superbuild/superbuild/paraview/build/bin/vtkWrapHierarchy-s3d @/builds/superbuild/superbuild/paraview/build/VTK/Common/Core/CMakeFiles/vtkCommonCore-hierarchy.Release.args -o /builds/superbuild/superbuild/paraview/build/lib/vtk/hierarchy/ParaView/vtkCommonCore-hierarchy.txt /builds/superbuild/superbuild/paraview/build/VTK/Common/Core/CMakeFiles/vtkCommonCore-hierarchy.data @/builds/superbuild/superbuild/paraview/build/VTK/Common/Core/CMakeFiles/vtkCommonCore-hierarchy.depends.args
vtkWrapHierarchy-s3d: In /sources/specifx/VTK/Common/Core/vtkDynamicLoader.h:47: attribute cannot be used here: vtk::filepath
This error suggest that, in your superbuild, the vtkWrapHierarchy-s3d executable is out-of-date. Try an “ls -l” on it to make sure that it was recompiled when you did the build.
we build inside a docker container, so everything should be freshly re-compiled
I did a fresh clone of @michal.wozniak’s branch and launched the build (still inside docker, so it’s especially fresh )
And I got the same error.
One important point is that we don’t get that error when building paraview by itself. We only get that error when building paraview using the superbuild.
We’ll continue to investigate.
Meanwhile, could you confirm my understanding?:
The __VTK_WRAP__ macro should not be defined during normal compilation
The __VTK_WRAP__ macro is defined inside vtk’s “compile tools” (which has it’s own bison/yacc parser, to parse the headers)
[[vtk::filepath]] should only appear during wrapping (hence the macro VTK_FILEPATH)
The error we have looks like the vtkWrapHierarchy-s3d doesn’t recognize the vtk::filepath attribute, even thought it should
Your understanding is correct on all points, but #4 is the critical one.
It looks like vtkWrapHierarchy doesn’t recognize the attribute. Which is why my first guess was that the vtkWrapHierarchy executable was an old one.
Another possibility is that something is causing problems with the parsing of vtkDynamicLoader.h. For example, maybe the superbuild is adding stuff to the include path that isn’t present in a stand-alone build. For example, maybe a header file somewhere has defined a macro with the name vtkLibHandle or OpenLibrary, and the error is a symptom of that. That’s just a wild guess, however.
I managed to get the build logs just for vtkWrapHierarchy-s3d (I build the docker in a way I could go inside and inspect/run stuff).
We can see that it builds from the /sources/... and it puts the object into the build directory, which is /builds/superbuild/superbuild/paraview/build/.
N.B. : current working directory is /builds/superbuild/superbuild/paraview/build/; and we use ninja as a generator
If you do something like ninja RenderingCore that build large chunks of VTK that don’t depend on wrapping, does that work? I’m just trying to figure out if the build issue is truly isolated to vtkWrapHierarchy.
Also, you say that you’re building your own fork of paraview. Does VTK’s paraview build?
I made a typo there, I meant “Kitware’s paraview”, not “VTK’s paraview”. I was just curious what was different between your fork and Paraview’s 5.10.1 release.
I, too, just finished another build. Where I completely removed our code. And it built correctly. Sorry for the confusion.
So even though the path passed to cmake was pointing elsewhere (to ParaView), and I had cleaned up the build folder. It was somehow still referencing our fork.
One thing that might not have been clear: we also have a fork of VTK.
I checked that the VTK/Wrapping directory matches exactly what’s in ParaView’s VTK. But I haven’t checked all the differences in the whole repository.
I’ll try to build our VTK on its own, with and without wrapping. I’ll probably try building ParaView with our VTK and our fork of ParaView with ParaView’s VTK.
Ah. This is one of the reasons the vtkWrappingTools used to be statically linked. But the distro folks (debian, if I recall correctly) insisted that statically linked libraries were evil and had to be purged from all packages. Eventually I caved in.
Like we already have our fork, we could maintain that on our own end. We’re going to have to manage different versions of VTK in any case, so if we could make our life easier by avoiding this kind of issue that would be great.
Also… are the vtkWrappingTools usually available from distro’s packages? I’m really wondering what were their reasoning behind insisting for dynamically linking something that is, as far as I know, just used at build-time?
P.S. My compliments on maintaining a Flex/Bison parser for C/C++ headers
)
