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.
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
We're going to use this header to provide shared macros. Right now, we
can use it to replace the:
#ifdef __cplusplus
extern "C" {
#endif
…
#ifdef __cplusplus
}
#endif
Stanzas for every installed header, with easier to read macros in the
same spirit of Cairo and GLib.
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.
Ensure that we also have import/export decorations for the prototypes, as
Visual Studio does not like such decorations on the function definitions
without the prototypes decorated as well, when the function prototypes
exist.
The only way these get used is when you choose to include epoxy/gl.h
but EGL/egl.h. I'm not sure that's something I want to actually
support, but piglit happened to do so, and this gets things working.
There's not as much support here as in real khrplatform.h, but then
there's no EGL for windows. And seriously, compilers support 64-bit
and float types, why would you even build this complexity?
We can't completely avoid it, since gl's headers use these defines for
their header guards, and we really do need to stop the system GL
headers from doing anything.
Fixes#14
For performance, I want to be able to make single-context (well,
single-pixel-format-and-device) apps be able to directly call GL
functions through function pointers. Bake that into the ABI now so I
can get a release out the door and fix this up later.
This also fixes the lack of __stdcall annotation on the
PFNWHATEVERPROC typedefs.
This lets the compiler generate faster function calls (call through
function pointer, instead of call into a linker-generated stub func
containing jump to function pointer).
I was thinking at one point that part of the build was going to
require not including the #defines from the generated code, but would
want these prototypes. It turns out that's not the case (and if it
is, I'll just wrap the #defines in an ifdef).
Emmanuele Bassi
Yaron Cohen-Tal
Chun-wei Fan
Eric Anholt