Additional cmake fixes over #2006

[gzotti]

Description

#2006 was merged too early. We must make sure that the program can be compiled even on systems where QtWebEngine does not exist (esp. ARM platform, but also a few others.)

This here attempts to

• Let cmake detect availability of QtWebEngine, or warn the user that a less functional alternative will be built
• Build the QtWebEngine-dependent GUI element on the fly.
• Useful behaviour with WSL
• Test on RaspberryOS
• Test in CI systems
• Test on MacOS

Note

There is a problem seen in the test system used: cmake on WSL/Ubuntu with qtwebengine5-dev not installed sees the installed Qt libraries in /mnt/c/qt (This is C:\Qt in the Windows file hierarchy and obviously the wrong place to access from WSL) when it does not find the really appropriate libraries in /usr. I hope this is a so radically absurd setting that CI and other ways of self-building deployment finds no problem with that. Else I need to know a way to specify that cmake must never access the wrong Qt installations.

The next issue on WSL is that building with QtWebEngine enabled results in a system where the OnlineQueries plugin fails to launch:

ERROR:gl_surface_glx_qt.cpp(141)] GLX 1.3 or later is required.
ERROR:gl_ozone_glx_qt.cpp(57)] GLSurfaceGLXQt::InitializeOneOff failed.
shared memfd open() failed: Die angeforderte Funktion ist nicht implementiert

So it's better to detect WSL with cmake and disable using QtWebEngine in this case.

Fixes #2006 (issue)

Screenshots (if appropriate):

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update

How Has This Been Tested?

Test Configuration:

• Operating systems:
  • Windows 10 / Qt5.13
  • WSL/Ubuntu 20.4 with Qt5.12.8
  • Raspberry OS (RPi4)
• Graphics Card: irrelevant

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[gzotti]

https://gitlab.kitware.com/cmake/cmake/-/issues/20878 describes a similar case. It seems there is no solution in this particular case. WSL users should certainly install the correct package as documented in the build instructions. The standalone CI systems should work, hopefully. I will try RPi4 next.

[alex-w]

@gzotti do you use Qt 5.12 or 5.15 in WSL?

[gzotti]

I run Ubuntu 20.04.3 LTS, where cmake finds Qt5.12.8. The problem is described above.
How would I update to 5.15, and/or switch between two installed versions on this platform? I have seen a lot of deprecation warnings in the CI logs when 5.15 is used.

[gzotti]

I think this is OK for now. Few people will run Stellarium on WSL, and compilation now creates a crash-safe application (OK, at least it does not crash over this issue...). I would merge when CI runs have completed without issues.

[github-actions]

Hello @gzotti! Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[github-actions]

Hello @gzotti! Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest