pv-5.8 build fails with protobuf_generate

ParaView Support
1

The SUSE builds on leap15.1 keep failing with this type of error:

CMake Error at build/ThirdParty/protobuf/lib64/cmake/paraview-5.8/protobuf-function.cmake:2 (protobuf_generate):
Unknown CMake command "protobuf_generate".
Call Stack (most recent call first):
 Remoting/ServerManager/CMakeLists.txt:194 (paraview_protobuf_generate)

Any idea what is provoking this?

2

Your system protobuf is likely not installing its CMake support. See the discussion here. Protobuf 3.4 should have it.

3

Hi @ben.boeckel - apart from the heavy-handed approach of not building when cmake < 3.13, any pointers about which protobuf version and/or packaging is needed? I’m using leap15.1, which is their newest stable version.

FYI: some discussions here

4

ParaView needs at least protobuf 3.4. Alternatively, using the bundled protobuf should be safe as well (we mangle to avoid conflicts with anything else using protobuf in ParaView’s process space (window manager communication tends to be the issue with protobuf specifically).

P.S. Your discussion link seems invalid.

5

Hi Ben (@ben.boeckel)!

The discussion link was on a branched project - seems to have been deleted in the meantime.

I just tried with a local build (also on leap15.1) and it seems to be going OK. Not sure what changed, but I did take another look at how the openSUSE package is being created and noticed that they have specifically enabled -DPARAVIEW_ENABLE_WEB - which sounds like it could be the thing making the difference.

Here is the listing of config parameters being used. Do you spot anything (or things) that could be the issue? I figure if we can knock out one of them and get a otherwise complete build, that would be a good thing™. At the moment we don’t have anything really workable for leap15.1

Thanks,
/mark

       -DPARAVIEW_BUILD_SHARED_LIBS:BOOL=ON \
       -DCMAKE_SKIP_RPATH:BOOL=OFF \
       -DPARAVIEW_USE_VTKM:BOOL=OFF \
       -DPARAVIEW_USE_QT:BOOL=ON \
       -DPARAVIEW_USE_PYTHON:BOOL=ON \
       -DPARAVIEW_PYTHON_SITE_PACKAGES_SUFFIX=%{_lib}/python%{py3_ver}/site-packages/paraview \
       -DPARAVIEW_ENABLE_WEB:BOOL=ON \
       -DVTK_WRAP_PYTHON:BOOL=ON \
       -DVTK_OPENGL_HAS_OSMESA:BOOL=OFF \
       -DBUILD_EXAMPLES:BOOL=OFF \
       -DBUILD_TESTING:BOOL=OFF \
       -DQtTesting_INSTALL_NO_DEVELOPMENT:BOOL=ON \
       -DVTK_BUILD_QT_DESIGNER_PLUGIN:BOOL=OFF \
       -DPARAVIEW_INSTALL_DEVELOPMENT_FILES:BOOL=ON \
       -DPARAVIEW_BUILD_WITH_EXTERNAL:BOOL=ON \
       -DVTK_MODULE_USE_EXTERNAL_VTK_gl2ps=%{?with_gl2ps:ON}%{!?with_gl2ps:OFF} \
       -DVTK_MODULE_USE_EXTERNAL_VTK_libharu=%{?with_haru:ON}%{!?with_haru:OFF} \
       -DVTK_MODULE_USE_EXTERNAL_VTK_pugixml=%{?with_pugixml:ON}%{!?with_pugixml:OFF}
6

Protobuf is pretty much always needed. It is the server/client communication container format thing. Web support wouldn’t change that.

7

I have a successful local build (also on leap15.1). I suspect that the -DPARAVIEW_BUILD_WITH_EXTERNAL:BOOL=ON entry might be doing it.

I tried overriding just that one with -DVTK_MODULE_USE_EXTERNAL_ParaView_protobuf=FALSE which had a very funny result. The cmake portion ran, but didn’t generate a Makefile.

Not sure which part of the equation is non-deterministic: cmake, paraview, operating system, myself :wink:

8

That would make it use external dependencies (where supported).

See if ThirdParty/protobuf/vtkprotobuf is run with the module-specific option set. cmake --trace-expand may help there (though it will generate a lot of output).