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>
Removing the files() statement allows us to not use source_root(), which
breaks using libepoxy as a sub-project.
Using the python3 module is better for Windows portability.
We have been building the shared library for Epoxy without the symbol
visibility flags for the compiler, which means we've been leaking
internal symbols all over the floor.
Fixes: #111
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.
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.
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.
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.
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.
The build is conditional on:
* using the Meson build
* passing the `-Denable-docs=true` configuration switch
* having `doxygen` installed
Currently, the generated HTML is kind of empty, but it works.
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
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 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.
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.
Emmanuele Bassi
Joseph C, Hill
Thomas Petazzoni
Emmanuele Bassi
Andrei Fadeev
Nirbheek Chauhan
Patrick Griffis