Skip to content

FindOpenGL: Add support for GLVND.

tfogal requested to merge tfogal/cmake:glvnd into master

Tradeoffs / options for defining variables in the face of libGLVND.

Some background: ideally, libGL would no longer be used. It's now a legacy library that is only for compatibility. GLVND supplies three independent libraries that a developer may want to use:

  • A target that uses OpenGL should link against libOpenGL
  • A target that uses glX should link against libGLX
  • A target that uses EGL should link against libEGL There is of course few situations where an application needs one of the latter two libraries but not the first library. However it can occur: it is conceivable that a shared library might contain only glX code, for example, and then be coupled with an application or library that had only OpenGL code (or vice-versa).

This creates some tradeoffs in how we define OPENGL_LIBRARIES on Linux:

  1. OPENGL_LIBRARIES contains libOpenGL only
  • Pro:
    • Explicit. Users are sure to ask for context they use.
    • Not possible to accidentally mix up context vs. GetProcAddress() fqn
  • Con:
    • Old CMake code is now broken, as basically every application expects to be able to use glX when linking OPENGL_LIBRARIES.
    • New interface is required for both glX and EGL. All users MUST learn this new interface.
  1. OPENGL_LIBRARIES contains libOpenGL and libGLX
  • Pro:
    • The semantics of OPENGL_LIBRARIES is maintained from version to version
    • Old CMake code still works.
  • Con:
    • EGL-only applications need to add something in to link correctly
    • EGL-only applications are stuck getting glX
    • Poor precedent for future. What if a new context system crops up? Or a new platform? This option blesses glX as "the" context library.
    • No guarantee that libGLX exists on the system. Does this degrade to option 1? Silently?
    • New interface is required for code that wants to use EGL.
  1. OPENGL_LIBRARIES contains libOpenGL and libEGL
  • Pro:
    • Easy to use EGL code.
  • Con:
    • Old CMake code is now broken, as basically every application expects to be able to use glX when linking OPENGL_LIBRARIES.
    • New interface is required for code that wants to use GLX.
    • No guarantee that libEGL exists on the system. Does this degrade to option 1? Silently?
    • Poor precedent for future w.r.t. "blessing" EGL, as above
  1. OPENGL_LIBRARIES contains libOpenGL, libEGL, and libGLX
  • Pro:
    • All currently-available options succeed
  • Con:
    • Almost all current applications do not use but link against libEGL.
    • It becomes easy for a developer to accidentally mismatch the context they create and the code they use for e.g. GetProcAddress()
    • There may be some environments which one of the context libraries but not the other.
    • Poor? precedent for future: blessing "all" options.
    • It becomes difficult to link 'only EGL' or 'only glX', complicating binary distribution of programs.
  1. OPENGL_LIBRARIES contents depend on new (advanced) 'USE' or similar options.
  • Pro:
    • target_link_libraries lines can remain unchanged
  • Con:
    • What are the defaults to the hypothetical USE_GLX and USE_EGL? We're back to options 1--4.
    • Or, require USE_EGL | USE_GLX to be specified, meaning the find_package line must be changed and all old CMake code breaks.
  1. OPENGL_LIBRARIES is empty && deprecated. New variable[s] are introduced for specifying the exact set of libraries that a developer may want.
  • Pro:
    • Explicitness means developer won't choose one library && use another
  • Con:
    • Old CMake code is now broken, as basically every application expects to be able to use glX when linking OPENGL_LIBRARIES.
  1. OPENGL_LIBRARIES contains libGL.
  • Pro:
    • GLX-based applications continue to work, for now.
  • Cons:
    • Risk of users doing Bad Things when they need EGL, such as linking against both libGL and libEGL. This is undefined behavior.
    • Developers must all derive custom behavior for EGL-based software.

The choice in this patch is (2). This is not meant to be an endorsement of that option, just a strawman.


Edited by Robert Maynard for better formatting

Topic-rename: FindOpenGL-glvnd

Edited by Brad King

Merge request reports