Preparing CMakeLists.txt to accept Wayland

[Escain]

Previously, CMakeLists.txt assume that Linux uses X11+OpenGL, and even override the USE_XLIB provided by the user.

With the current changes, XLIB is searched, and only used when found, otherwise, we fallback to WAYLAND (currently much more in use).
For OpenGL, a similar approach is implemented: OpenGL is used if found, but GLES2 can be used otherwise, or even enforced -DUSE_GLES2.

This change is a requirement for WAYLAND implementation, and GLES2 for embedded.

Those changes should not affect Windows and Apple, and only imply change for those using Wayland or GLES2, which are currently not supported.

[gkv311]

I would object from the configure logic that automatically enables or disables dependencies based on their appearnce in the system.

One would say 'lets automatically enable VTK, FreeImage, FFmpeg, whatever, if found', which could be nice for 'build them all I don't care' users. But this would cause a nightmare for making builds with predictable and intended configurations - as some options will suddently popup or will be skipped just based on what user has been installed in the system before first configure.

I would suggest instead adding dedicated options to enable/disable dependency from Xlib (OCCT already have it) and Wayland (to be introduced). And let OCCT developers to decide which options to turn on by default in CMake (NOT by probing if this library's development files are installed or not in the system). End-users and OCCT package managers willl decide which options to turn on based on their preferences. I would expect that Xlib will be left enabled by default - but this could be changed in the future.

Feel free also to reuse my attempts to add Wayland support to OCCT, if this is your final goal (a couple of unfonished commits from my branch):

• a6bf837
• 2579c83

[dpasukhi]

The test system not use full list of 3rd party. My apologies.
I will extend the testing with full list of components. It will be ready during that month.
Additionally testing do not compare results right now, only building process needs to validate.
The main test system - our internal, we will initiate testing on our side after completing of preparation of your ticket :)
Feel free to clarify any point, it will be a pleasure to help.

Best regards, Dmitrii.

[dpasukhi]

@gkv311 can OCCT team adapt your code for integration?

[gkv311]

@gkv311 can OCCT team adapt your code for integration?

I have no objections.

[dpasukhi]

Thank you! I will plan that activities if contributor will have problems with integrations.

[Escain]

Hi,

Thanks @gkv311, your project is much more advanced, consequently, I will restart my adaptation from your commit.

How much time should I expect for OCCT integration to happens? In case it's short (few weeks), it's probably worth to wait and use master.

[dpasukhi]

Right now I'm working on Tests system (in my free time 😅)
So, the current issue is the next for me in case no other will arrive from community (additionally I have problem with MacOS viewer functionality, that have the same priority as currently).
So, I expect that will be done approximately 1 month later (begin of December).

[dpasukhi]

@Escain to have an integrated into repo you will need to proceed with CLA.
The links: Contribution Guide
Or https://dev.opencascade.org/get_involved
My apologies, i forgot about that point.
_
Sorry, miss click with closing.