Working with the superbuild of Paraview 5.7.0 with the tarball as source. I have independently installed pv on two computers in a network that tap from the same grand set of programs and shared libraries. Also the so-called ‘external settings’ in cache of ccmake (file CMakeCache.txt) are the same.
I am at loss finding out why, in one of the two systems, the compilation and install does create the executables pvdataserver, pvrenderserver and pvserver and does not generate hydra_pmi_proxy, mpiexec and paraview.
I have redirected the stdout and stderr of the compilation process (make -j8 2>&1 | tee logfile) to a file and, for both computers, grep -i "error" does not report errors occurring. I can’t seem to find a reason why such important files are not created in equal conditions (save oversights that may become evident at some point). This should depend on some miss that I fail to see.
Any tip and directions to clear up the confusion following from this is welcome.
Thanks in advance for it.
The fact that a paraview executable has not been build can be an indication that the rendering engine selected (egl, qt5, mesa, omesa, …) does not prescribe this. On second looks with a fresh pair of eyes, it appeared indeed that the two sets of build variables were not the same, as claimed earlier. They differed for the rendering engine: ENABLE_qt5=ON creates paraview and ENABLE_egl=ON does not. So the report above was an XFAIL situation, and human error once again. Hope this helps.
Just a point to raise. You seems to confuse the Rendering engine and Qt5.
Qt5 is not a rendering engine, it is just the UI library we use to build the ParaView executable. Without it, no paraview executable.
It so happens that certain rendering engine (egl) are not compatible with Qt5.
ParaView supports multiple rendering engines including egl , mesa , osmesa , and qt5 . All of these are incompatible with each other. If none of these are chosen, a UI-less ParaView will be built (basically just pvpython ). On Windows and macOS, only the qt5rendering engine is available.
ParaView supports multiple rendering engines including OpenGL and EGL (mutually exclusive). These may be used by different frontends including Mesa, OSMesa, or Qt5 (each mutually exclusive). Without Qt5, a UI-less ParaView will be built and Qt5 is the only supported frontend for Windows and macOS.
Please note that at generation ccmake throws an error when Qt_5 and EGL are selected at the same time.
CMake Error at CMakeLists.txt:182 (message): Cannot enable EGL and Qt at the same time.
Call Stack (most recent call first):
superbuild/CMakeLists.txt:151 (superbuild_sanity_check)
It is then not just a question of editing the readme file, but also of coding the build rules accordingly.
Happy to help, but it’s nothing more than some linguistic editing. You know what happens under the hood and it up to the developers’ responsibility to endorse it. This having been said…
Paraview supports either OpenGL or EGL as rendering engine. The frontends supported are Qt5 for OpenGL, and Mesa and OSMesa for both OpenGL and EGL. Qt5 is the only frontend for Windows and macOS; frontends are mutually exclusive for Linux. A ParaView built without Qt5 will have no user interface.
Paraview supports either OpenGL or EGL as rendering engine. OpenGL accepts either Qt5, Mesa or OSMesa as frontend, while EGL accepts either Mesa or OSMesa. For Windows and macOS only the pair OpenGL/Qt5 is permitted. A ParaView built without Qt5 will have no user interface.
@mwestphal It would then be desirable that, beyond terminological questions, the README of the Superbuild file explains which logic is implemented in the error messages. So users can back trace their errors and, forewarned, avoid them forearmed. Maybe it is already there, but a double check would do no harm, and perhaps a lot of good.
To the future reader. I had edited the post title believing it had been [solved]. In fact the discussions on the merge requests in the issue tracker have proven more controversial then expected. Please disregard that [solved] and proceed at your own risk.