The new GL registry XML contains the 'glsc2' identifier for the OpenGL
SC 2.0 API. We can safely ignore it, since we don't really know what to
do with it, at the moment.
We should explicitly add the include directory under the mingw64
toolchain to the C arguments when cross-compiling, just like we add the
libdir to the link flags.
On UNIX-like OSes, the OS will read the shebang and use the correct
interpreter, and on Windows, Meson will read the shebang and use the
correct interpreter.
Adding it manually will cause python to try to interpret python
Use the appropriate Markdown syntax (with GitHub extensions) for code
blocks and preformatted bits, and update the build instructions and
dependencies for Meson and Ninja.
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.
We need to explicitly link against gdi32 in order to access
SetPixelFormat and ChoosetPixelFormat, and the order of the linking is
relevant when using static libraries. This is a slight workaround to the
order of compiler arguments generated by Meson, and it's supposed to go
away in the near future.
Meson uses plain text files for describing the cross-compilation
environment, binaries, and properties.
The values are taken from the mingw wrapper around configure that
Fedora provides for autotools projects.
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.
The gen_dispatch.py script relies on the source and include directories
to exist before dumping the files in there, split by type, in order to
sustain the split of the headers existing in a separate root from the
source files. This causes a spooky-action-at-a-distance scenario where
headers are generated by rules inside the source directory but influence
the contents of a separate directory — and require a separate set of
rules to install those headers.
Different build systems would require either splitting the generation in
to two separate passes (which is more expensive and time consuming), or
generate the header and source files in the same directory, and just
tweak the inclusion paths accordingly.
Since we want to maintain this fiction for the autotools build, but
ignore it for different build systems, let's add a separate set of
arguments for gen_dispatch.py that make the rules inside Makefile.am
work appropriately.
Define PACKED for Visual Studio builds, so that we can try to reduce
our library size for Visual Studio builds. Add a ENDPACKED macro
that is currently defined only for Visual Studio builds as packing is
done via __pragma(pack(push,n), that should be popped when done.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
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.
Certain X server do not have GLX enabled or supported, such as x2go. We
can handle this case gracefully inside libepoxy.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
EGL is available on different platforms, so we should favor it, if
available. This also allows us to decouple EGL from GLX, and use the
former without the latter being compiled in.
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>
Binding an API does not change the type of the current context. Even if
it did, EGL 1.5 treats EGL_OPENGL_API and EGL_OPENGLES_API as identical
for this purpose. If you want to know properties of the current
context, query it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Some X server not supporting any OpenGL feature, glXQueryExtensionsString
will return NULL and causes the function to fail.
Thanks to Emmanuel Stapf (manus@eiffel.com) for the original patch.
This was verified running an application on macOS while the X server was
running on Windows Xming 7.5.0.10
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
The code used to check this symbol, but commit 689abf4 replaced it with
GLX_H, presumably to work better with either Mesa or Khronos headers.
But nVidia's header use the older include guard. Add it as another
option.
Should fix the headerguards.c compile test when the system glx.h is from
nVidia's binary drivers.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
...so that the generated code are buildable by pre-2013 Visual Studio.
The main thing that this does is that we avoid named initializers, but
instead initialize the structs in old-school C89 way.
The generated code may not look that robust, but since this is generated
code, I think this is not that much an issue; when the Khronos registry gets
updated, all that is needed is that the code gets re-generated, and we have the
items in the right order.
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.
If the '--force' switch is not passed to autoreconf, the autotools will
try to reuse the generated files committed in the Git repo, which hard
code the names and versions of the tools originally used to generate
them.
Binding an API does not change the type of the current context. Even if
it did, EGL 1.5 treats EGL_OPENGL_API and EGL_OPENGLES_API as identical
for this purpose. If you want to know properties of the current
context, query it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Emmanuele Bassi
Emmanuele Bassi
Nirbheek Chauhan
Patrick Griffis
Chun-wei Fan
Adam Jackson
Yaron Cohen-Tal
Simon Parzer
Martin Castillo
Olivier Blin
Daniel Wolf
Bryan Kadzban
Caleb Anderson