# pv-5.8 build fails with protobuf\_generate
**URL:** https://discourse.paraview.org/t/pv-5-8-build-fails-with-protobuf-generate/4250
**Category:** ParaView Support
**Created:** [May 4, 2020, 6:59pm UTC](https://discourse.paraview.org/t/pv-5-8-build-fails-with-protobuf-generate/4250 "2020-05-04T18:59:32Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [May 4, 2020, 6:59pm UTC](https://discourse.paraview.org/t/pv-5-8-build-fails-with-protobuf-generate/4250/1 "2020-05-04T18:59:33Z")
The SUSE builds on leap15.1 keep failing with this type of error:
```auto
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?
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [May 5, 2020, 12:04am UTC](https://discourse.paraview.org/t/pv-5-8-build-fails-with-protobuf-generate/4250/2 "2020-05-05T00:04:37Z")
Your system protobuf is likely not installing its CMake support. See the discussion [here](https://github.com/GobySoft/goby3/issues/58#event-3281199578). Protobuf 3.4 should have it.
---
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [May 6, 2020, 6:45am UTC](https://discourse.paraview.org/t/pv-5-8-build-fails-with-protobuf-generate/4250/3 "2020-05-06T06:45:48Z")
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](https://build.opensuse.org/package/show/home:badshah400:branches:science/paraview)
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [May 6, 2020, 2:14pm UTC](https://discourse.paraview.org/t/pv-5-8-build-fails-with-protobuf-generate/4250/4 "2020-05-06T14:14:03Z")
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.
---
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [May 6, 2020, 6:40pm UTC](https://discourse.paraview.org/t/pv-5-8-build-fails-with-protobuf-generate/4250/5 "2020-05-06T18:40:23Z")
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
```auto
-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}
```
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [May 6, 2020, 11:24pm UTC](https://discourse.paraview.org/t/pv-5-8-build-fails-with-protobuf-generate/4250/6 "2020-05-06T23:24:32Z")
Protobuf is pretty much always needed. It is the server/client communication container format thing. Web support wouldn’t change that.
---
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [May 7, 2020, 12:31pm UTC](https://discourse.paraview.org/t/pv-5-8-build-fails-with-protobuf-generate/4250/7 "2020-05-07T12:31:30Z")
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 😉
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [May 7, 2020, 5:21pm UTC](https://discourse.paraview.org/t/pv-5-8-build-fails-with-protobuf-generate/4250/8 "2020-05-07T17:21:29Z")
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).