summaryrefslogtreecommitdiff
path: root/meson.build
Commit message (Collapse)AuthorAgeFilesLines
...
* 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-151-1/+4
| | | | This way, we don't have to depend on Python2 on newer OSes.
* Remove the shebang from gen_dispatch.pyEmmanuele Bassi2017-02-151-1/+4
| | | | | | | | 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.
* 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.
* 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.
* Merge pull request #100 from centricular/fix-find_programEmmanuele Bassi2017-02-081-5/+0
|\ | | | | meson: Don't call find_program objects with python
| * meson: Don't call find_program objects with pythonNirbheek Chauhan2017-01-281-5/+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-061-1/+1
| |
* | Encode Epoxy capabilities into the pkg-config fileEmmanuele Bassi2017-02-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | 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 supportEmmanuele Bassi2017-02-061-3/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Generate the Epoxy API reference using DoxygenEmmanuele Bassi2017-02-031-0/+9
| | | | | | | | | | | | | | | | | | | | 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.
* | Merge branch 'symbol-visibility'Emmanuele Bassi2017-01-311-0/+17
|\ \
| * | Improve consistency of the symbol visibilityEmmanuele Bassi2017-01-251-0/+17
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Clean up some Meson usagePatrick Griffis2017-01-271-4/+4
|/
* build: Drop '-Wall' from the checked compiler argumentsEmmanuele Bassi2017-01-251-1/+0
| | | | Meson adds `-Wall` for us with `warning_level=1`.
* build: Explicitly link against gdi32Emmanuele Bassi2017-01-251-0/+14
| | | | | | | | 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-251-4/+21
| | | | | | | | | | | | | | | | | | | | | 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/+125
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.
View Lorry Controller Status