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.
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
This way we can take a dist tarball created through autotools, and use
Meson to build it.
Once Meson gets support for disting, we'll do the same with the
autotools build files, and call the result a "Buildoboros".
PyLint raises a bunch of issues on the dispatch generation script with
regards to best practices; most of those issues are real, so let's fix
the code to be more Pythonic.
On Linux and other Unix variants we may not have access to GLX and EGL
at run time. Dependent libraries can only discover this by using dlsym()
on various symbols, because as soon as they attempt to call those
symbols through Epoxy, Epoxy will abort. This means that a bunch of code
needs to be copy-pasted between projects, with the high chance of
somebody getting it wrong.
Epoxy already has all the internals needed to detect whether GLX and EGL
are available, so exposing a simple API is a better alternative.
Fixes#73
Since Epoxy can be built with different platform-specific API, having a
way for dependent projects to discover those capabilities without
necessarily crashing the minute they attempt to use them is a good
feature to have.
We strongly direct library and application developers to use pkg-config
in order to use Epoxy, so it makes sense to add variables to the
epoxy.pc file that can be easily extracted at configuration time.
Currently, GLX support in libepoxy at build time is hard coded, but
various platforms have expressed their preference for having a
configure-time option for it.
For instance:
- various embedded distributors do not ship with X11, but wish to use
libraries that depend on libepoxy now that Wayland is available
- distributors for macOS still wish to retain the ability to ship
their software with X11 enabled
By default, we want epoxy to build with GLX enabled pretty much
everywhere it makes sense, since it's only a build-time option and it's
not a run-time dependency.
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.
When checking whether GLX or EGL are available on the system, we don't
want to use the internal API that forces an exit() on missing libraries
and symbols — as that would defeat the point.
Instead, we should have safe functions to call internally that simply
return a NULL pointer, so we can bail out ourselves in a controlled
fashion.
The build is conditional on:
* using the Meson build
* passing the `-Denable-docs=true` configuration switch
* having `doxygen` installed
Currently, the generated HTML is kind of empty, but it works.
We don't really use `sudo` anywhere, except for installing packages;
this means we should be able to use the faster container-based
environment on Travis, instead of the VM-based one.
Emmanuele Bassi
Emmanuele Bassi
Tommy Marrinan