| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
A small bug was noticed during debian packaging.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| | |
I've come around to the various contributors' positions: X11 on OSX is
basically dead, and we're not serving our users by trying to support
it.
|
| | |
| |
| |
| |
| | |
OS X support shouldn't depend on X11 being installed on the host.
Removes the X11 dependency.
|
| |/
|
|
|
|
|
| |
We don't ever explicity link against libEGL, so no need to make use of
EGL_LIBS.
Fixes #30.
|
| | |
|
| |
|
|
| |
We'd need a dlvsym() equivalent.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The new linker requires that the consumers of a library link against
the libraries that that library depends on, which is supported by
Libs.private.
Fixes #16
|
| |
|
|
|
| |
There's no linker flag of this name in the normal clang, presumably
beause the linker feature doesn't exist.
|
| | |
|
| |
|
|
|
| |
It doesn't exist. There's EAGL, but that's not something we're
covering.
|
| | |
|
| |
|
|
| |
This is very poorly tested at this point, but survives a simple testcase.
|
| | |
|
| |
|
|
|
| |
It now builds successfully builds a .dll file. Not that it's usable
or anything yet.
|
| | |
|
| |
|
|
|
|
|
| |
Note that the generated code is still generated, they just aren't
built and installed. The goal with that is that someone could take
the built .c and .h files and drop it into their own project, if they
want to avoid shared libs.
|
| |
|
|
|
| |
Well, not quite. One of the regression tests is failing with
GLXBadFBConfig in that build. Not sure why.
|
| | |
|
| | |
|
|
|
Not actually working yet, but it's a snapshot to start from.
|