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.
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.
Meson is a Python-based build system that generates build rules of
Ninja, Visual Studio, and XCode. It's designed to be fast, and have a
small, non-Turing complete language to describe the build process,
tests, and dependencies. It's simpler than CMake, and faster than
autotools.
As a direct comparison in terms of speed, three build and check runs for
libepoxy from a clean Git repository clone yield these results on my
Kabylake Core i7 7500U (nproc=4):
- Autotools (make)
Run #1 (cold) real: 22.384s, user: 20.011s, sys: 3.689s
Run #2 (warm) real: 22.429s, user: 20.220s, sys: 3.708s
Run #3 (warm) real: 22.068s, user: 19.743s, sys: 3.594s
- Meson (ninja)
Run #1 (cold) real: 5.932s, user: 9.371s, sys: 1.625s
Run #2 (warm) real: 6.273s, user: 10.066, sys: 1.740s
Run #3 (warm) real: 5.796s, user: 9.233s, sys: 1.607s
Which means that Meson and ninja are approximately 4x faster than
autotools.
In terms of simplicity, the autotools build takes six files and a total
of 645 lines; Meson requires 3 files, and 361 lines to achieve the same
result. Additionally, Meson automatically builds in a separate build
directory and does not leave files inside the source directory; and Meson
does not use libtool.
Since Meson is quite new and still actively developed, we're going to
leave the autotools build in place for a while, with the intention of
switching to Meson in the future.
It's pretty much pointless to build and run tests for a library that we
know is not available.
The Meson build already skips the GLES 1.0 test, so let's make the
Autotools build do the same.
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.
These LDFLAGS go to the compiler, and getting the arg to the linker
requires -Wl or -Xlinker. gcc apparently was passing this through
anyway, while clang was getting angry.
Fixes failure of the X Server with glamor using desktop GL on EGL, and
the associated testcase in the tree. This was clearly just
copy-and-paste failure on my part in
b251e3ae33.
This increases the size of the library, but avoids some of the
concerns that have been brought up with the library silently switching
you from glWhateverEXT() to glWhatever() if there might be slight
behavior differences between the two that hadn't been identified. The
downside is that it means we can't share the resolver functions among aliases.
This fixes crashes on ARM's Mali drivers, where desktop GL isn't
supported, and epoxy didn't notice the error and tried to dlsym() on
libGL.so.1.
An alternative would have been to look at the response from
eglQueryAPI() first, but that would have meant that we still need to
BindAPI in the case that eglQueryAPI returns something like VG or CL,
and so we needed to handle these errors regardless.
Fixes#22
Epoxy dlsym()s directly into libEGL instead of using dlsym() on a NULL
handle, so we can't relying on ELF resolution like we do for dlopen().
Instead, just override epoxy's function pointers for the functions
epoxy will call in the process of getting one of these bootstrap
functions.
This is a lot shorter to type, and still gets the dependencies to work
(tested with touch src/dispatch_common.c; make check, and touch
src/egl_common.c; make check).
Efraim Flashner
Emmanuele Bassi
Adam Jackson
Olivier Blin
Yaron Cohen-Tal
Eric Anholt
Chun-wei Fan
Matt Turner