The WGL tests should not include "config.h", since we're trying to test
the use of Epoxy, not its internals.

After doing this for Meson in commit fc014fa1, let's do the same dance
for the Autotools build.

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.

And avoid an out of bounds access warning.

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.

These have dlsym versions of GLIBC_2.3 and GLIBC_2.2, respectively.

Signed-off-by: Adam Jackson <ajax@redhat.com>

See sysdeps/unix/sysv/linux/arm/libdl.abilist in glibc

Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>

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.