summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Add explicit version flags for macOS buildsmacos-version-infoEmmanuele Bassi2017-03-071-2/+6
| | | | | | | | Autotools automatically adds version related linker flags on macOS that are not related to the version information. Since we want to maintain binary compatibility, we should do the same when building on macOS. Fixes: #108
* Add z,relro and z,now to the GCC linker flagsEmmanuele Bassi2017-03-031-1/+1
| | | | | | | | | | | | | These flags are mitigations against memory corruption bugs, and are typically enabled by Linux distributions hardening rules. We only use these flags with GCC, similarly to `-Bsymbolic`. More information on relro is available here: - http://tk-blog.blogspot.co.uk/2009/02/relro-not-so-well-known-memory.html - http://mudongliang.github.io/2016/07/11/relro-a-not-so-well-known-memory-corruption-mitigation-technique.html - https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_RELRO_.28ld_-z_relro.29
* Merge pull request #107 from anholt/issue-106Emmanuele Bassi2017-03-034-8/+8
|\ | | | | Add C++ guards around generated headers
| * Add C++ guards around generated headersEmmanuele Bassi2017-03-034-8/+8
|/ | | | | | | | | Commit 0625a74d69f762df8d411bc0451927424aee1f2c moved the C++ guards after the inclusion of the generated headers, which was an unintended behavioural change and now requires header guards around the inclusion of Epoxy headers. Fixes: #106
* Release Epoxy 1.4.1 (stable)1.4.1Emmanuele Bassi2017-03-022-2/+2
|
* Remove /W3 from the MSVC compiler flagsEmmanuele Bassi2017-03-011-1/+0
| | | | Meson already uses /W2, like it uses -Wall with GCC.
* Simplify the code generation rules for MesonEmmanuele Bassi2017-03-012-136/+64
| | | | | | | | | | | | The code generation rules are explicitly built for each supported API target, but they ought to be refactored since they are pretty much identical. In order to do that, we can store the arguments to the custom_target rules inside an array and then iterate over each element. This cuts down the complexity of the Meson build, and the chances of getting something wrong due to duplication.
* Merge branch 'python-gen-dispatch'Emmanuele Bassi2017-02-155-3/+20
|\
| * Annotate build issues with MesonEmmanuele Bassi2017-02-151-0/+4
| | | | | | | | | | | | We depend on an older version of Meson; once we can bump up the minimum version, we'll be able to fix a couple of less than optimal uses of the Meson API.
| * Allow using Python3 to run gen_dispatch.pyEmmanuele Bassi2017-02-152-2/+5
| | | | | | | | This way, we don't have to depend on Python2 on newer OSes.
| * Remove the shebang from gen_dispatch.pyEmmanuele Bassi2017-02-154-2/+12
|/ | | | | | | | Instead of having Meson determine the invocator through the shebang line we explicitly pass the script file to the Python interpreter. This will allow us to either use Python3 or Python2, or whatever Python.exe is available on Windows.
* doc: Check for 'dot' and add the relevant configurationEmmanuele Bassi2017-02-152-4/+45
| | | | | We don't really use it, right now, but it may come in handy later, and it doesn't cost us anything, since the whole thing is optional anyway.
* doc: Ignore C++ guard macrosEmmanuele Bassi2017-02-151-1/+1
| | | | We don't need Doxygen to care about those.
* Annotate new Epoxy symbolsEmmanuele Bassi2017-02-152-0/+4
| | | | API added in 1.4 should be annotated as such.
* Hide Appveyor YAML fileEmmanuele Bassi2017-02-151-0/+0
| | | | | Like we do for the TravisCI YAML file, use the leading dot notation to hide the Appveyor YAML file from directory listing on Unix-like OSes.
* Update the "why not GLEW" sectionEmmanuele Bassi2017-02-101-2/+1
| | | | | | GLEW has grown support for OpenGL 3.2+ core contexts over the years. Everything else has stayed pretty much the same, though, so you should still use Epoxy over libGLEW.
* Add the Appveyor build badgeEmmanuele Bassi2017-02-101-0/+1
| | | | Gamifying the development experience, once achievement at a time.
* Define a macro directory in the autotools buildEmmanuele Bassi2017-02-103-0/+5
| | | | | | | | | | | | | As libtool suggest we do; this also allows using ACLOCAL_AMFLAGS inside build that create a separate environment with their own m4 macros, like jhbuild and Cerberus. In order to avoid a warning from autoreconf, we create the empty macros directory during the autogen.sh step; aclocal would create the directory for us anyway, but different versions of autotools may have different behaviours. Closes: #58
* Merge branch 'appveyor'Emmanuele Bassi2017-02-101-0/+67
|\ | | | | | | Closes #95
| * Add Appveyor scriptTommy Marrinan2017-02-101-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | Appveyor is a CI infrastructure like Travis, but oriented at building on Windows environment, as opposed to Linux and macOS. By using Appveyor we can test changes to Epoxy and make sure that Windows builds won't break. Additionally, Appveyor allows to deploy build artefacts, which means we can generate builds for Epoxy releases. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
| * Remove unnecessary bits from the documentation build rulesEmmanuele Bassi2017-02-101-14/+1
| | | | | | | | | | We don't need to list the source files as we use a glob rule in the Doxyfile itself.
* | Remove unnecessary bits from the documentation build rulesEmmanuele Bassi2017-02-101-14/+1
|/ | | | | We don't need to list the source files as we use a glob rule in the Doxyfile itself.
* Ignore non-build branches in TravisEmmanuele Bassi2017-02-091-0/+5
| | | | | | The khronos-registry branch contains only the registry XML files. The debian branch contains the Debian packaging files.
* Add TravisCI build badge to the READMEEmmanuele Bassi2017-02-091-0/+2
|
* Update the TravisCI environment to use DockerEmmanuele Bassi2017-02-091-20/+14
| | | | | | | | | | | | | | | | | The Travis environment is terribly outdated, and they are not really subtly pushing people to use Docker to set up their own containerised CI environments instead of pulling from Ubuntu 12.04 or 14.04. Let's try using this approach: - create a Docker image that pulls from Debian Stretch - set up a build and test environment - push the image to the Docker Hub - create a derived Docker image that copies the Epoxy repo when running under Travis - run the build and test script inside the derived image This is similar to what Meson does for its CI.
* Add compiler arguments for MSVC buildsEmmanuele Bassi2017-02-091-1/+24
| | | | | | | | | We're using a bunch of compiler arguments when building with GCC and compilers that expose a GCC compatibility layer, but we should also have warnings when building with MSVC. GLib has a bunch of compiler arguments, taken from the "Win32 Programming" book, that we can reuse.
* Add editorconfig fileEmmanuele Bassi2017-02-081-0/+30
| | | | | | The editorconfig[0] format is getting traction in various code editors. [0]: http://editorconfig.org/
* Drop unnecessary inclusion of "config.h"Emmanuele Bassi2017-02-084-4/+1
| | | | | The WGL tests should not include "config.h", since we're trying to test the use of Epoxy, not its internals.
* Test compiler arguments for the appropriate compilerEmmanuele Bassi2017-02-081-33/+38
| | | | | MSVC does not expose GCC-compatible compiler arguments, so there's no point in even trying.
* Update the symbol visibility rules under MSVCEmmanuele Bassi2017-02-081-1/+5
| | | | | | | | | | | | | | For the Visual Studio C compiler we need to annotate our public symbols with `__declspec(dllimport)` to ensure they are visible when dynamically linking to Epoxy's DLL. This is needed because under Windows we use a dispatch table, instead of wrapper functions, thus the symbol visibility rules change. Compiling with MingW will automatically add `__declspec(dllimport)` for us. Thanks to Nirbheek Chauhan for the help in debugging the issue. Fixes #104
* Add Meson build files to the autotools distEmmanuele Bassi2017-02-081-4/+20
| | | | | | | | This way we can take a dist tarball created through autotools, and use Meson to build it. Once Meson gets support for disting, we'll do the same with the autotools build files, and call the result a "Buildoboros".
* Document the process for updating the registryEmmanuele Bassi2017-02-081-0/+13
| | | | | This avoids each maintainer to transmit the knowledge orally to the next maintainer.
* Do not use Python 3 to run gen_dispatch.pyEmmanuele Bassi2017-02-081-1/+1
| | | | | It's still a Python 2.x script, even if it's mostly compatible with Python 3.x.
* 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-083-13/+0
|\ | | | | meson: Don't call find_program objects with python
| * meson: Don't call find_program objects with pythonNirbheek Chauhan2017-01-283-13/+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
* | Bump version to 1.4 for releasev1.41.4.0Emmanuele Bassi2017-02-062-2/+2
| |
* | Add API to allow for platform detectionEmmanuele Bassi2017-02-066-3/+64
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-032-0/+22
| | | | | | | | | | | | Similar to `epoxy_has_glx()`, but for the EGL windowing system API.
| * | Add epoxy_has_glx()Emmanuele Bassi2017-02-032-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-067-46/+129
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since X11 can be used on multiple platforms, or disabled in special environments, we should provide a way to control whether or not Epoxy is built with GLX support. Fixes anholt/libepoxy#52 Fixes anholt/libepoxy#63 Closes anholt/libepoxy#80 Closes anholt/libepoxy#81
| * | | Encode Epoxy capabilities into the pkg-config fileEmmanuele Bassi2017-02-063-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since Epoxy can be built with different platform-specific API, having a way for dependent projects to discover those capabilities without necessarily crashing the minute they attempt to use them is a good feature to have. We strongly direct library and application developers to use pkg-config in order to use Epoxy, so it makes sense to add variables to the epoxy.pc file that can be easily extracted at configuration time.
| * | | Allow enabling and disabling GLX support, part IIEmmanuele Bassi2017-02-062-39/+79
| | | | | | | | | | | | | | | | | | | | After doing this for Meson in commit fc014fa1, let's do the same dance for the Autotools build.
| * | | Allow enabling and disabling GLX supportEmmanuele Bassi2017-02-064-9/+34
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | doc: Ignore a private symbolEmmanuele Bassi2017-02-061-1/+1
| | |
* | | Generate a ChangeLog for the dist tarballEmmanuele Bassi2017-02-061-0/+11
| | | | | | | | | | | | It's useful for people that like rummaging inside tarballs.
* | | Generate xz tarballs on distcheckEmmanuele Bassi2017-02-061-1/+1
| | | | | | | | | | | | Both gz and bz2 tarballs are discouraged, in this day and age.
* | | Drop additional stdbool.h include directivesEmmanuele Bassi2017-02-061-2/+0
|/ /
View Lorry Controller Status