glvnd has the rather nice property that GLX and (desktop) GL are
available in separate libraries. As an example this would allow an EGL
app to use desktop GL without any X11 libraries. Fix up our dlopens to
prefer the glvnd libraries if available and fall back to the old ABI if
not.
Signed-off-by: Adam Jackson <ajax@redhat.com>
It is perfectly possible to build Mesa3D with just OpenGL support, and
use with GLX in X.org, without having EGL/OpenGLES support.
However, libepoxy currently unconditionally requires EGL support in its
configure.ac, which causes a build failure when Mesa3D only provides
full OpenGL support:
checking for EGL... no
configure: error: Package requirements (egl) were not met:
Package egl was not found in the pkg-config search path.
Perhaps you should add the directory containing `egl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'egl', required by 'world', not found
This commit fixes that by:
- Adjusting the configure.ac to add a --{enable,disable}-egl option
handled in the exact same way as --{enable,disable}-glx
- Adjusting the meson build logic in the same way.
- Adjusting src/dispatch_common.h to define PLATFORM_HAS_EGL correctly,
which allows to not include any EGL related header file if EGL
support is not enabled.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We can build Epoxy with different compilers on Linux, and they may not
support all the linker flags we wish to use, so we should check whether
or not they exist.
Related commit: b3b8bd9af7
Fix "epoxy_glx_version" to handle the case when GLX is not active on the display.
Patch is tweak from the original version posted by Tom Horsley
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
Removing the files() statement allows us to not use source_root(), which
breaks using libepoxy as a sub-project.
Using the python3 module is better for Windows portability.
We have been building the shared library for Epoxy without the symbol
visibility flags for the compiler, which means we've been leaking
internal symbols all over the floor.
Fixes: #111
Using GCC is not a guarantee of also having access to the Linux linker;
just like we use specific linker flags on macOS, the symbolic and relro
linker flags are pretty much Linux specific.
Autotools automatically adds version related linker flags on macOS that
are not related to the version information. Since we want to maintain
binary compatibility, we should do the same when building on macOS.
Fixes: #108
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.
We depend on an older version of Meson; once we can bump up the minimum
version, we'll be able to fix a couple of less than optimal uses of the
Meson API.
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.
Emmanuele Bassi
Adam Jackson
Tom Schoonjans
Emmanuele Bassi
Daniel Stone
Joseph C, Hill
Thomas Petazzoni
Gianfranco Costamagna
Efraim Flashner
Andrei Fadeev