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
Client extensions are always available, and are only listed in
eglQueryString(dpy=NULL). Without this we can't call anything from e.g.
EXT_platform_base.
Signed-off-by: Adam Jackson <ajax@redhat.com>
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.
The dlopen bits are left in place, but the functions required the
types, and in the case of EGL, the types require that the platform
header actually exists.
Unfortunately, for GLX 1.4+ entrypoints (just glxGetProcAddress
currently) or extensions, if there isn't a context bound then we don't
have a dpy and screen available to provide useful debug messages. Oh
well.
Emmanuele Bassi
Adam Jackson
Yaron Cohen-Tal
Eric Anholt
Fredrik Höglund