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.
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.
This reverts commit de84448e3a.
In order to make Epoxy build on Travis with the Precise package set, we
need to revert this commit, as the autotools version shipped on Ubuntu
12.04 bail out at the missing macro directory — whereas newer versions
just create it if needed.
Updating the Travis environment to Trusty allows the build to finish,
but have the knock-on effect of making more tests run — and the
EGL-without-GLX tests fail. Since there's nothing newer than Trusty on
Travis, we should back out this change until we have the ability to
build a suitable test/CI environment.
The new GL registry XML contains the 'glsc2' identifier for the OpenGL
SC 2.0 API. We can safely ignore it, since we don't really know what to
do with it, at the moment.
We should explicitly add the include directory under the mingw64
toolchain to the C arguments when cross-compiling, just like we add the
libdir to the link flags.
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
Use the appropriate Markdown syntax (with GitHub extensions) for code
blocks and preformatted bits, and update the build instructions and
dependencies for Meson and Ninja.
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
Tommy Marrinan
Emmanuele Bassi
Emmanuele Bassi
Nirbheek Chauhan
Patrick Griffis