Epoxy can be compiled with GLX and X11 native resources on EGL. We can
disable the former, but the latter is always built in when enabling EGL
support.
Some platforms do not support X11 at all, so we need a way to disable
X11 when configuring Epoxy.
If the system we're building Epoxy on has GL and EGL pkg-config modules,
then we should add them to the Requires.private field of the pkg-config
file.
The Requires.private field does not contribute to the linker flags
generated by pkg-config, unless we're doing a static build; it does,
however, contribute to the compiler flags generated by pkg-config, which
means that platforms that specify ad hoc compiler flags for their GL and
EGL implementations via pkg-config will be able to propagate them
through Epoxy.
Closes: #139
It is perfectly possible to build Mesa3D with just OpenGL support, and
use with GLX in X.org, without having EGL/OpenGLES support.
However, libepoxy currently unconditionally requires EGL support in its
configure.ac, which causes a build failure when Mesa3D only provides
full OpenGL support:
checking for EGL... no
configure: error: Package requirements (egl) were not met:
Package egl was not found in the pkg-config search path.
Perhaps you should add the directory containing `egl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'egl', required by 'world', not found
This commit fixes that by:
- Adjusting the configure.ac to add a --{enable,disable}-egl option
handled in the exact same way as --{enable,disable}-glx
- Adjusting the meson build logic in the same way.
- Adjusting src/dispatch_common.h to define PLATFORM_HAS_EGL correctly,
which allows to not include any EGL related header file if EGL
support is not enabled.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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
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.
This reverts commit de84448e3a.
In order to make Epoxy build on Travis with the Precise package set, we
need to revert this commit, as the autotools version shipped on Ubuntu
12.04 bail out at the missing macro directory — whereas newer versions
just create it if needed.
Updating the Travis environment to Trusty allows the build to finish,
but have the knock-on effect of making more tests run — and the
EGL-without-GLX tests fail. Since there's nothing newer than Trusty on
Travis, we should back out this change until we have the ability to
build a suitable test/CI environment.
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.
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
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.
Emmanuele Bassi
Thomas Petazzoni
Eric Anholt
Christopher Meng
Ryan Houdek