third_party
/
libepoxy
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
571 Commits
1 Branch
0 Tags
1.8 MiB
Tag: Branch: Tree: 0a304d1a25
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '0a304d1a25'
${ noResults }
libepoxy/include/epoxy/meson.build

44 lines
1.2 KiB
Raw Normal View History Unescape

Add common header We're going to use this header to provide shared macros. Right now, we can use it to replace the: #ifdef __cplusplus extern "C" { #endif … #ifdef __cplusplus } #endif Stanzas for every installed header, with easier to read macros in the same spirit of Cairo and GLib.
8 years ago
headers = [ 'common.h' ]
Simplify the code generation rules for Meson 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.
8 years ago
# GL is always generated
generated_headers = [ [ 'gl.h', 'gl_generated.h', gl_registry ] ]
build: Rework the build rules for generated files in Meson 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.
8 years ago
if build_egl
Simplify the code generation rules for Meson 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.
8 years ago
generated_headers += [ [ 'egl.h', 'egl_generated.h', egl_registry ] ]
build: Rework the build rules for generated files in Meson 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.
8 years ago
endif
if build_glx
Simplify the code generation rules for Meson 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.
8 years ago
generated_headers += [ [ 'glx.h', 'glx_generated.h', glx_registry ] ]
build: Rework the build rules for generated files in Meson 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.
8 years ago
endif
if build_wgl
Simplify the code generation rules for Meson 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.
8 years ago
generated_headers += [ [ 'wgl.h', 'wgl_generated.h', wgl_registry ] ]
build: Rework the build rules for generated files in Meson 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.
8 years ago
endif
Simplify the code generation rules for Meson 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.
8 years ago
gen_headers = []
foreach g: generated_headers
header = g[0]
gen_header = g[1]
registry = g[2]
generated = custom_target(gen_header,
input: registry,
output: [ gen_header ],
command: [
gen_dispatch_py,
'--header',
'--no-source',
'--outputdir=@OUTDIR@',
'@INPUT@',
],
install: true,
install_dir: join_paths(epoxy_includedir, 'epoxy'))
gen_headers += [ generated ]
headers += [ header ]
endforeach
Move epoxy_headers definition into include/epoxy In order to properly depend on headers, both generated and provided, in a separate directory, we need to refer to them using their path. Generated headers already have their full path; for provided ones, we can simply use the `files()` directive. This change should allow using libepoxy as a Meson subproject. Fixes: #115
8 years ago
epoxy_headers = files(headers) + gen_headers
build: Rework the build rules for generated files in Meson 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.
8 years ago
install_headers(headers, subdir: 'epoxy')