Epoxy should provide a function that returns the version of the GL
shading language in use, in the same vein as it allows to get the
version of GL.
Closes: #145
The EGL_EXT_device_query extension introduces the
eglQueryDeviceStringEXT() function, which can be used with an
EGLDeviceEXT enumeration to receive an OpenGL extension string
containing all of the device extensions supported by it. From the
EGL_EXT_device_query spec's amendments to section "3.2 Devices" after
"3.1 Errors":
const char *eglQueryDeviceStringEXT(EGLDeviceEXT device,
EGLint name);
returns a pointer to a static, zero-terminated string describing
some aspect of the specified EGLDeviceEXT. <name> must be
EGL_EXTENSIONS.
Since OpenGL extension parsing is rather simple, and we could always run
into additional cases similar to this one in the future, we expose the
shared epoxy_extension_in_string() function in libepoxy's public headers
so that users can save themselves the hassle of having to write their
own extension parser.
Signed-off-by: Lyude Paul <thatslyude@gmail.com>
In order to properly depend on headers, both generated and provided, in
a separate directory, we need to refer to them using their path.
Generated headers already have their full path; for provided ones, we
can simply use the `files()` directive.
This change should allow using libepoxy as a Meson subproject.
Fixes: #115
Commit 0625a74d69 moved the C++ guards
after the inclusion of the generated headers, which was an unintended
behavioural change and now requires header guards around the inclusion
of Epoxy headers.
Fixes: #106
The code generation rules are explicitly built for each supported API
target, but they ought to be refactored since they are pretty much
identical.
In order to do that, we can store the arguments to the custom_target
rules inside an array and then iterate over each element.
This cuts down the complexity of the Meson build, and the chances of
getting something wrong due to duplication.
Instead of having Meson determine the invocator through the shebang
line we explicitly pass the script file to the Python interpreter.
This will allow us to either use Python3 or Python2, or whatever
Python.exe is available on Windows.
For the Visual Studio C compiler we need to annotate our public symbols
with `__declspec(dllimport)` to ensure they are visible when dynamically
linking to Epoxy's DLL.
This is needed because under Windows we use a dispatch table, instead of
wrapper functions, thus the symbol visibility rules change. Compiling
with MingW will automatically add `__declspec(dllimport)` for us.
Thanks to Nirbheek Chauhan for the help in debugging the issue.
Fixes#104
Libraries and applications that depend on Epoxy currently have no way to
safely degrade functionality if they are used on a platform without GLX
support; the only way to achieve that is to perform a symbol check
themselves, by essentially copying what Epoxy already does.
By exposing `epoxy_has_glx()`, those libraries and applications now have
the chance of querying Epoxy itself and gracefully handle failure.
Older versions of the Microsoft Visual C compiler do not support C99 and
do not have stdbool.h.
Additionally, Epoxy is pretty much C89 compliant, and stdbool.h is part
of C99.
We can add a simple fallback for MSVC, in case we end up getting built
with it.
On UNIX-like OSes, the OS will read the shebang and use the correct
interpreter, and on Windows, Meson will read the shebang and use the
correct interpreter.
Adding it manually will cause python to try to interpret python
To avoid a symbols file on Windows, Epoxy annotates all the publicly
visible symbols directly in the source, but uses the default symbol
visibility everywhere else. This means that only some symbols are
annotated as `EPOXY_IMPORTEXPORT`, and generally only on Windows.
Additionally, Epoxy has a private 'PUBLIC' pre-processor macro for
internal use, which duplicates the `EPOXY_IMPORTEXPORT` but contains
more logic to detect GCC, in case we're building with GCC on Windows.
This would be enough, except that EGL is also available on Windows,
which means we'd have to annotate the exported `epoxy_*` API inside
epoxy/egl.h as well. At that point, though, we should probably avoid
any confusion, and adopt a single symbol visibility policy across the
board.
This requires some surgery of the generated and common dispatch sources,
but cuts down the overall complexity:
- there is only one annotation, `EPOXY_PUBLIC`, used everywhere
- the annotation detection is done at Epoxy configuration time
- only annotated symbols are public, on every platform
- annotated symbols are immediately visible from the header
We're going to use this header to provide shared macros. Right now, we
can use it to replace the:
#ifdef __cplusplus
extern "C" {
#endif
…
#ifdef __cplusplus
}
#endif
Stanzas for every installed header, with easier to read macros in the
same spirit of Cairo and GLib.
Instead of using a generator and having to deal with tweaking the
inclusion paths, we can use a custom target rule, which will do the
right thing and put the generate files where we expect them to be.
Due to how Meson and Ninja work we need to be a bit more careful as to
how we deal with dependencies and generated files, especially since
Epoxy is built on the assumption that the only inclusion path for the
headers lies under the 'include' sub-directory.
First of all, we need to split the dispatch table generation into two
separate steps, one for the headers and one for the source files.
Additionally, we need to munge the paths of the non-generated headers
so that we reference them by their correct path.
These changes are necessary to ensure that Epoxy can be built on a
system without Epoxy installed already; the previous Meson-based build
system relied on the headers being installed in a system directory.
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>
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.
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.
Ensure that we also have import/export decorations for the prototypes, as
Visual Studio does not like such decorations on the function definitions
without the prototypes decorated as well, when the function prototypes
exist.
The only way these get used is when you choose to include epoxy/gl.h
but EGL/egl.h. I'm not sure that's something I want to actually
support, but piglit happened to do so, and this gets things working.
There's not as much support here as in real khrplatform.h, but then
there's no EGL for windows. And seriously, compilers support 64-bit
and float types, why would you even build this complexity?
We can't completely avoid it, since gl's headers use these defines for
their header guards, and we really do need to stop the system GL
headers from doing anything.
Fixes#14
For performance, I want to be able to make single-context (well,
single-pixel-format-and-device) apps be able to directly call GL
functions through function pointers. Bake that into the ABI now so I
can get a release out the door and fix this up later.
This also fixes the lack of __stdcall annotation on the
PFNWHATEVERPROC typedefs.
This lets the compiler generate faster function calls (call through
function pointer, instead of call into a linker-generated stub func
containing jump to function pointer).
When initially writing the Makefiles, I started from a Makefile.am
that had ajax's copyright instead of an Intel one. The only line I
can see that's left from the original Makefile.am is "pkgconfigdir" in
the root Makefile.am.
Note that the generated code is still generated, they just aren't
built and installed. The goal with that is that someone could take
the built .c and .h files and drop it into their own project, if they
want to avoid shared libs.
This totally replaces the getprocaddress and dlsym code, which was
basically just stubs up until now. The is_glx/is_egl() is also
dropped -- they weren't doing anything, and the only false answer they
could give is if the dlopen were to fail.
I was thinking at one point that part of the build was going to
require not including the #defines from the generated code, but would
want these prototypes. It turns out that's not the case (and if it
is, I'll just wrap the #defines in an ifdef).
Emmanuele Bassi
Lyude Paul
Adam Jackson
Nirbheek Chauhan
Patrick Griffis
Bryan Kadzban
Yaron Cohen-Tal
Chun-wei Fan
Eric Anholt
Fredrik Höglund