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.
GLEW has grown support for OpenGL 3.2+ core contexts over the years.
Everything else has stayed pretty much the same, though, so you should
still use Epoxy over libGLEW.
As libtool suggest we do; this also allows using ACLOCAL_AMFLAGS inside
build that create a separate environment with their own m4 macros, like
jhbuild and Cerberus.
In order to avoid a warning from autoreconf, we create the empty macros
directory during the autogen.sh step; aclocal would create the directory
for us anyway, but different versions of autotools may have different
behaviours.
Closes: #58
Appveyor is a CI infrastructure like Travis, but oriented at building on
Windows environment, as opposed to Linux and macOS.
By using Appveyor we can test changes to Epoxy and make sure that
Windows builds won't break.
Additionally, Appveyor allows to deploy build artefacts, which means we
can generate builds for Epoxy releases.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
The Travis environment is terribly outdated, and they are not really
subtly pushing people to use Docker to set up their own containerised CI
environments instead of pulling from Ubuntu 12.04 or 14.04.
Let's try using this approach:
- create a Docker image that pulls from Debian Stretch
- set up a build and test environment
- push the image to the Docker Hub
- create a derived Docker image that copies the Epoxy repo
when running under Travis
- run the build and test script inside the derived image
This is similar to what Meson does for its CI.
We're using a bunch of compiler arguments when building with GCC and
compilers that expose a GCC compatibility layer, but we should also have
warnings when building with MSVC.
GLib has a bunch of compiler arguments, taken from the "Win32
Programming" book, that we can reuse.
Thomas Petazzoni
Emmanuele Bassi
Emmanuele Bassi
Gianfranco Costamagna
Efraim Flashner
Andrei Fadeev
Tommy Marrinan