delta/libepoxy.git/src/meson.build, branch macos-version-info

Add explicit version flags for macOS builds

2017-03-07T11:52:26+00:00

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 flags

2017-03-03T16:58:46+00:00

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

Simplify the code generation rules for Meson

2017-03-01T12:36:00+00:00

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.

Remove the shebang from gen_dispatch.py

2017-02-15T14:09:01+00:00

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.

Merge pull request #100 from centricular/fix-find_program

2017-02-08T12:57:47+00:00

meson: Don't call find_program objects with python

Merge branch 'symbol-visibility'

2017-01-31T18:09:34+00:00

meson: Don't call find_program objects with python

2017-01-28T01:24:10+00:00

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

build: Clean up some Meson usage

2017-01-28T00:13:48+00:00

Improve consistency of the symbol visibility

2017-01-25T12:43:17+00:00

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

build: Explicitly link against gdi32

2017-01-25T12:41:02+00:00

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.