Some X server not supporting any OpenGL feature, glXQueryExtensionsString
will return NULL and causes the function to fail.
Thanks to Emmanuel Stapf (manus@eiffel.com) for the original patch.
This was verified running an application on macOS while the X server was
running on Windows Xming 7.5.0.10
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
The code used to check this symbol, but commit 689abf4 replaced it with
GLX_H, presumably to work better with either Mesa or Khronos headers.
But nVidia's header use the older include guard. Add it as another
option.
Should fix the headerguards.c compile test when the system glx.h is from
nVidia's binary drivers.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
...so that the generated code are buildable by pre-2013 Visual Studio.
The main thing that this does is that we avoid named initializers, but
instead initialize the structs in old-school C89 way.
The generated code may not look that robust, but since this is generated
code, I think this is not that much an issue; when the Khronos registry gets
updated, all that is needed is that the code gets re-generated, and we have the
items in the right order.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Most of the changes that happened after commit 8bbc0d40 broke epoxy
pretty much irreparably because of the CMake build and the attempt at
making libepoxy a static library that can be copy-pasted into another
project without generating files.
Since all the commits are entangled, and are full of unrelated changes,
we cannot simply do a localized set of reverts; instead, we need to hit
the reset button.
From this point forward, we're going to improve libepoxy's build while
attempting to keep the existing build system working. This may mean
reinstating the CMake build system at a later date.
If the '--force' switch is not passed to autoreconf, the autotools will
try to reuse the generated files committed in the Git repo, which hard
code the names and versions of the tools originally used to generate
them.
Binding an API does not change the type of the current context. Even if
it did, EGL 1.5 treats EGL_OPENGL_API and EGL_OPENGLES_API as identical
for this purpose. If you want to know properties of the current
context, query it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The code used to check this symbol, but commit 689abf4 replaced it with
GLX_H, presumably to work better with either Mesa or Khronos headers.
But nVidia's header use the older include guard. Add it as another
option.
Should fix the headerguards.c compile test when the system glx.h is from
nVidia's binary drivers.
will return NULL and causes the function to fail. Thanx to Emmanuel Stapf (manus@eiffel.com) for the original patch.
This was verified running an application on macOS while the X server was running
on Windows Xming 7.5.0.10
...so that the generated code are buildable by pre-2013 Visual Studio.
The main thing that this does is that we avoid named initializers, but
instead initialize the structs in old-school C89 way.
The generated code may not look that robust, but since this is generated
code, I think this is not that much an issue; when the Khronos registry gets
updated, all that is needed is that the code gets re-generated, and we have the
items in the right order.
Since our provider enums are small, we can store them as bytes or
shorts if we just let the compiler know that it's OK. Saves 20kb in
the compiled library.
Daniel Wolf
Yaron Cohen-Tal
Bryan Kadzban
Chun-wei Fan
Emmanuele Bassi
Adam Jackson
Caleb Anderson
Simon Parzer
Olivier Blin
Eric Anholt