summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Update gen_dispatch after a pass of pylintEmmanuele Bassi2017-02-081-46/+44
| | | | | | PyLint raises a bunch of issues on the dispatch generation script with regards to best practices; most of those issues are real, so let's fix the code to be more Pythonic.
* Merge pull request #100 from centricular/fix-find_programEmmanuele Bassi2017-02-081-4/+0
|\ | | | | meson: Don't call find_program objects with python
| * meson: Don't call find_program objects with pythonNirbheek Chauhan2017-01-281-4/+0
| | | | | | | | | | | | | | | | 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
* | Add API to allow for platform detectionEmmanuele Bassi2017-02-064-3/+62
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Linux and other Unix variants we may not have access to GLX and EGL at run time. Dependent libraries can only discover this by using dlsym() on various symbols, because as soon as they attempt to call those symbols through Epoxy, Epoxy will abort. This means that a bunch of code needs to be copy-pasted between projects, with the high chance of somebody getting it wrong. Epoxy already has all the internals needed to detect whether GLX and EGL are available, so exposing a simple API is a better alternative. Fixes #73
| * | Add epoxy_has_egl()Emmanuele Bassi2017-02-031-0/+21
| | | | | | | | | | | | Similar to `epoxy_has_glx()`, but for the EGL windowing system API.
| * | Add epoxy_has_glx()Emmanuele Bassi2017-02-031-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Libraries and applications that depend on Epoxy currently have no way to safely degrade functionality if they are used on a platform without GLX support; the only way to achieve that is to perform a symbol check themselves, by essentially copying what Epoxy already does. By exposing `epoxy_has_glx()`, those libraries and applications now have the chance of querying Epoxy itself and gracefully handle failure.
| * | Add conservative functions for checking platform symbolsEmmanuele Bassi2017-02-032-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When checking whether GLX or EGL are available on the system, we don't want to use the internal API that forces an exit() on missing libraries and symbols — as that would defeat the point. Instead, we should have safe functions to call internally that simply return a NULL pointer, so we can bail out ourselves in a controlled fashion.
| * | Drop additional stdbool.h include directivesEmmanuele Bassi2017-02-031-2/+0
| | |
* | | Allow enabling and disabling GLX supportEmmanuele Bassi2017-02-061-5/+3
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Write the API referenceEmmanuele Bassi2017-02-033-12/+169
| | | | | | | | | | Now that we have Doxygen generating it, we should fill out the API reference for Epoxy.
* | Merge branch 'symbol-visibility'Emmanuele Bassi2017-01-317-37/+27
|\ \
| * | Improve consistency of the symbol visibilityEmmanuele Bassi2017-01-257-37/+27
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | gen_dispatch: Ignore 'glsc2' APIEmmanuele Bassi2017-01-311-0/+2
| | | | | | | | | | | | 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.
* | build: Clean up some Meson usagePatrick Griffis2017-01-271-4/+4
|/
* build: Explicitly link against gdi32Emmanuele Bassi2017-01-251-2/+1
| | | | | | | | 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.
* build: Rework the build rules for generated files in MesonEmmanuele Bassi2017-01-252-47/+101
| | | | | | | | | | | | | | | | | | | | | 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.
* build: Add Meson build filesEmmanuele Bassi2017-01-251-0/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* build: Split arguments for dispatch generatorEmmanuele Bassi2017-01-252-9/+33
| | | | | | | | | | | | | | | | | | | | 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.
* MSVC Builds: Support PACKEDChun-wei Fan2017-01-252-0/+7
| | | | | | | | | 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>
* build: Hide mkdirEmmanuele Bassi2017-01-251-1/+4
| | | | | We don't really need to mess the log when creating the include directory in the build directory.
* Ensure we don't assert if GLX is not availableEmmanuele Bassi2017-01-251-0/+6
| | | | | | | 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>
* Do not call errx() on platforms without itEmmanuele Bassi2017-01-251-1/+1
| | | | Like, say, Windows.
* Use EGL to retrieve pointers if availableEmmanuele Bassi2017-01-251-16/+20
| | | | | | 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.
* Use the appropriate GLES library name for WindowsYaron Cohen-Tal2017-01-251-0/+4
| | | | | | Shared libraries on Windows use `.dll` for the extension, not `.so`. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
* add glBindRenderbufferEXT to half_aliasesSimon Parzer2017-01-251-0/+2
| | | | | | | | it seems like this was forgotten, because glBindFramebufferEXT is already there for the same reason Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
* egl: Be somewhat aware of EGL client extensionsAdam Jackson2017-01-181-7/+2
| | | | | | | | 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>
* egl: Fix the query for the current context's APIAdam Jackson2017-01-181-22/+6
| | | | | | | | | 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>
* Avoid C99 declaration after statementEmmanuele Bassi2016-12-071-2/+3
| | | | The rest of the library is C89-only, so we should keep it that way.
* support newer/larger gl.xmlDaniel Wolf2016-12-071-7/+9
| | | | Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
* Check for NULL extensions stringYaron Cohen-Tal2016-12-071-0/+2
| | | | | | | | | | | | 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>
* src/gen_dispatch.py: Make Generated Code Build Under C89Chun-wei Fan2016-12-071-2/+3
| | | | | | | | | | | | | | ...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>
* Revert all changes since 8bbc0d40Emmanuele Bassi2016-12-0714-136939/+245
| | | | | | | | | | | | | | | 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.
* build: Drop autogenerated autotools files from GitEmmanuele Bassi2016-11-071-882/+0
| | | | | | | | | These files should not be under revision control. This commit partially reverts: * 06fd4a271ad88476d8c6a37d49b6a8af5a11d988 * 62e384129b5b9243634ca4a71108c6f8699a24bd
* Fox some X server not supporting any OpenGL feature, glXQueryExtensionsStringYaron Cohen-Tal2016-07-291-0/+2
| | | | | | | will return NULL and causes the function to fail. Thanx 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
* Update pregenerated files.Yaron Cohen-Tal2015-11-034-3932/+3952
|
* Merge branch "oncer/half_aliases_fix".Yaron Cohen-Tal2015-11-031-2/+5
|\
| * add glBindRenderbufferEXT to half_aliasesSimon Parzer2015-11-031-0/+2
| | | | | | | | | | | | it seems like this was forgotten, because glBindFramebufferEXT is already there for the same reason
| * src/gen_dispatch.py: Make Generated Code Build Under C89Chun-wei Fan2015-07-281-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | ...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.
* | Make "epoxy_current_context_is_egl" visible.Yaron Cohen-Tal2015-10-311-3/+1
| |
* | Fix "epoxy_egl_get_current_gl_context_api" to use "eglQueryContext" with ↵Yaron Cohen-Tal2015-10-311-25/+7
| | | | | | | | "EGL_CONTEXT_CLIENT_TYPE" as "attribute".
* | Fix "epoxy_glx_version" to handle the case when GLX is not active on the ↵Yaron Cohen-Tal2015-09-291-14/+15
| | | | | | | | display.
* | Update pregenerated files.Yaron Cohen-Tal2015-09-224-4969/+74516
| |
* | Merge branch "nephatrine/registry-support".Yaron Cohen-Tal2015-09-221-7/+9
|\ \
| * | support newer/larger gl.xmlDaniel Wolf2015-09-211-7/+9
| |/
* | Fix support for a static build of Epoxy. Add support building and running ↵Yaron Cohen-Tal2015-09-036-146/+120
| | | | | | | | tests with CMake. Add support for linking with the static run-time library with MSVC.
* | Fix a bug in which "DllMain" isn't called when using the static version of ↵Yaron Cohen-Tal2015-08-304-64/+128
| | | | | | | | Epoxy in Windows.
* | Remove redundant code in "epoxy_get_bootstrap_proc_address".Yaron Cohen-Tal2015-08-301-9/+1
| |
* | Add support for building static libs with CMake. Fix file permissions. ↵Yaron Cohen-Tal2015-08-272-18/+41
| | | | | | | | Update documentation about building static libs and about using OpenGL ES / EGL.
* | Add some files to the repo so that it's possible to build without running ↵Yaron Cohen-Tal2015-08-262-2/+882
| | | | | | | | "autogen.sh".
* | Add support for CMake (no support for building/running the tests yet). Fix ↵Yaron Cohen-Tal2015-08-2610-72/+67100
| | | | | | | | support for Android. Add built-in support for building with EGL support (using "khrplatform.h" and "eglplatform.h" which are distributed together with Epoxy, and should work with any platform).
View Lorry Controller Status