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_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.
Thanks @mwestphal for clarifying this. Then here is something to fix/debate in https://gitlab.kitware.com/paraview/paraview-superbuild/blob/master/README.md, where it is stated that (boldface is mine)
ParaView supports multiple rendering engines including
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
qt5 rendering engine is available.
which guided my associations
@ben.boeckel @utkarsh.ayachit : What would be the right formulation here ?
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):
It is then not just a question of editing the readme file, but also of coding the build rules accordingly.
Oh, yes. Qt5 requires OpenGL; EGL is not supported. That should be included in the reword in my comment.
@XavierStuvw : Do you think you could take care of this rewording ? That would be very nice of you.
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.
Is this nice enough? Please feel free to edit.
Perfect. I also meant for you to contribute to contribute on our gitlab, as ParaView is an open source project open to external contribution as well.
Here is the correction :
You have been quick. I also thought of this
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.
I will consider contributing directly in the future as my familiarity with Paraview grows. For the moment my primary interest is to get it working in parallel: vtkSocketCommunicator errors: "Could not receive tag" and "Endian handshake failed" – with apologies for the shameless promotion of my pains.
A consensus has not been found. I have closed the MR.
@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.