|
|
|
project('libepoxy', 'c', version: '1.5.1',
|
build: Add Meson build files
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.
8 years ago
|
|
|
default_options: [
|
|
|
|
'buildtype=debugoptimized',
|
build: Add Meson build files
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.
8 years ago
|
|
|
'c_std=gnu99',
|
|
|
|
'warning_level=1',
|
|
|
|
],
|
|
|
|
license: 'MIT',
|
|
|
|
meson_version: '>= 0.44.0')
|
build: Add Meson build files
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.
8 years ago
|
|
|
|
|
|
|
epoxy_version = meson.project_version().split('.')
|
|
|
|
epoxy_major_version = epoxy_version[0].to_int()
|
|
|
|
epoxy_minor_version = epoxy_version[1].to_int()
|
|
|
|
epoxy_micro_version = epoxy_version[2].to_int()
|
|
|
|
|
|
|
|
epoxy_prefix = get_option('prefix')
|
|
|
|
epoxy_libdir = join_paths(epoxy_prefix, get_option('libdir'))
|
|
|
|
epoxy_datadir = join_paths(epoxy_prefix, get_option('datadir'))
|
|
|
|
epoxy_includedir = join_paths(epoxy_prefix, get_option('includedir'))
|
|
|
|
|
|
|
|
cc = meson.get_compiler('c')
|
|
|
|
host_system = host_machine.system()
|
|
|
|
|
|
|
|
conf = configuration_data()
|
|
|
|
conf.set_quoted('PACKAGE_NAME', meson.project_name())
|
|
|
|
conf.set_quoted('PACKAGE_VERSION', meson.project_version())
|
|
|
|
conf.set_quoted('PACKAGE_STRING', '@0@-@1@'.format(meson.project_name(), meson.project_version()))
|
|
|
|
conf.set_quoted('PACKAGE_DATADIR', join_paths(get_option('prefix'), get_option('datadir')))
|
|
|
|
conf.set_quoted('PACKAGE_LIBDIR', join_paths(get_option('prefix'), get_option('libdir')))
|
|
|
|
conf.set_quoted('PACKAGE_LOCALEDIR', join_paths(get_option('prefix'), get_option('datadir'), 'locale'))
|
|
|
|
conf.set_quoted('PACKAGE_LIBEXECDIR', join_paths(get_option('prefix'), get_option('libexecdir')))
|
|
|
|
conf.set('HAVE_KHRPLATFORM_H', cc.has_header('KHR/khrplatform.h'))
|
build: Add Meson build files
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.
8 years ago
|
|
|
|
|
|
|
# GLX can be used on different platforms, so we expose a
|
|
|
|
# configure time switch to enable or disable it; in case
|
|
|
|
# the "auto" default value is set, we only enable GLX
|
|
|
|
# support on Linux and Unix
|
|
|
|
enable_glx = get_option('glx')
|
|
|
|
if enable_glx == 'auto'
|
|
|
|
build_glx = not ['windows', 'darwin', 'android', 'haiku'].contains(host_system)
|
|
|
|
else
|
|
|
|
build_glx = enable_glx == 'yes'
|
|
|
|
endif
|
|
|
|
|
|
|
|
enable_egl = get_option('egl')
|
|
|
|
if enable_egl == 'auto'
|
|
|
|
build_egl = not ['windows', 'darwin'].contains(host_system)
|
|
|
|
else
|
|
|
|
build_egl = enable_egl == 'yes'
|
|
|
|
endif
|
|
|
|
|
|
|
|
enable_x11 = get_option('x11')
|
|
|
|
if not enable_x11
|
|
|
|
if enable_glx == 'yes'
|
|
|
|
error('GLX support is explicitly enabled, but X11 was disabled')
|
|
|
|
endif
|
|
|
|
build_glx = false
|
|
|
|
endif
|
|
|
|
|
|
|
|
# The remaining platform specific API for GL/GLES are enabled
|
|
|
|
# depending on the platform we're building for
|
|
|
|
if host_system == 'windows'
|
build: Add Meson build files
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.
8 years ago
|
|
|
build_wgl = true
|
|
|
|
has_znow = true
|
|
|
|
elif host_system == 'darwin'
|
|
|
|
build_wgl = false
|
|
|
|
has_znow = false
|
|
|
|
else
|
|
|
|
build_wgl = false
|
|
|
|
has_znow = true
|
|
|
|
endif
|
|
|
|
|
|
|
|
conf.set10('ENABLE_GLX', build_glx)
|
|
|
|
conf.set10('ENABLE_EGL', build_egl)
|
|
|
|
conf.set10('ENABLE_X11', enable_x11)
|
|
|
|
|
build: Add Meson build files
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.
8 years ago
|
|
|
# Compiler flags, taken from the Xorg macros
|
|
|
|
if cc.get_id() == 'msvc'
|
|
|
|
# Compiler options taken from msvc_recommended_pragmas.h
|
|
|
|
# in GLib, based on _Win32_Programming_ by Rector and Newcomer
|
|
|
|
test_cflags = [
|
|
|
|
'-we4002', # too many actual parameters for macro
|
|
|
|
'-we4003', # not enough actual parameters for macro
|
|
|
|
'-w14010', # single-line comment contains line-continuation character
|
|
|
|
'-we4013', # 'function' undefined; assuming extern returning int
|
|
|
|
'-w14016', # no function return type; using int as default
|
|
|
|
'-we4020', # too many actual parameters
|
|
|
|
'-we4021', # too few actual parameters
|
|
|
|
'-we4027', # function declared without formal parameter list
|
|
|
|
'-we4029', # declared formal parameter list different from definition
|
|
|
|
'-we4033', # 'function' must return a value
|
|
|
|
'-we4035', # 'function' : no return value
|
|
|
|
'-we4045', # array bounds overflow
|
|
|
|
'-we4047', # different levels of indirection
|
|
|
|
'-we4049', # terminating line number emission
|
|
|
|
'-we4053', # an expression of type void was used as an operand
|
|
|
|
'-we4071', # no function prototype given
|
|
|
|
'-we4819', # the file contains a character that cannot be represented in the current code page
|
|
|
|
]
|
|
|
|
elif cc.get_id() == 'gcc' or cc.get_id() == 'clang'
|
|
|
|
test_cflags = [
|
|
|
|
'-Wpointer-arith',
|
|
|
|
'-Wmissing-declarations',
|
|
|
|
'-Wformat=2',
|
|
|
|
'-Wstrict-prototypes',
|
|
|
|
'-Wmissing-prototypes',
|
|
|
|
'-Wnested-externs',
|
|
|
|
'-Wbad-function-cast',
|
|
|
|
'-Wold-style-definition',
|
|
|
|
'-Wdeclaration-after-statement',
|
|
|
|
'-Wunused',
|
|
|
|
'-Wuninitialized',
|
|
|
|
'-Wshadow',
|
|
|
|
'-Wmissing-noreturn',
|
|
|
|
'-Wmissing-format-attribute',
|
|
|
|
'-Wredundant-decls',
|
|
|
|
'-Wlogical-op',
|
|
|
|
'-Werror=implicit',
|
|
|
|
'-Werror=nonnull',
|
|
|
|
'-Werror=init-self',
|
|
|
|
'-Werror=main',
|
|
|
|
'-Werror=missing-braces',
|
|
|
|
'-Werror=sequence-point',
|
|
|
|
'-Werror=return-type',
|
|
|
|
'-Werror=trigraphs',
|
|
|
|
'-Werror=array-bounds',
|
|
|
|
'-Werror=write-strings',
|
|
|
|
'-Werror=address',
|
|
|
|
'-Werror=int-to-pointer-cast',
|
|
|
|
'-Werror=pointer-to-int-cast',
|
|
|
|
'-fno-strict-aliasing',
|
|
|
|
'-Wno-int-conversion',
|
|
|
|
]
|
|
|
|
else
|
|
|
|
test_cflags = []
|
|
|
|
endif
|
|
|
|
|
|
|
|
common_cflags = cc.get_supported_arguments(test_cflags)
|
build: Add Meson build files
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.
8 years ago
|
|
|
|
|
|
|
libtype = get_option('default_library')
|
|
|
|
|
|
|
|
# Visibility compiler flags; we only use this for shared libraries
|
|
|
|
visibility_cflags = []
|
|
|
|
if libtype == 'shared'
|
Improve consistency of the symbol visibility
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
8 years ago
|
|
|
if host_system == 'windows'
|
|
|
|
conf.set('DLL_EXPORT', true)
|
|
|
|
conf.set('EPOXY_PUBLIC', '__declspec(dllexport) extern')
|
|
|
|
if cc.get_id() != 'msvc'
|
Improve consistency of the symbol visibility
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
8 years ago
|
|
|
visibility_cflags += [ '-fvisibility=hidden' ]
|
|
|
|
endif
|
|
|
|
else
|
|
|
|
conf.set('EPOXY_PUBLIC', '__attribute__((visibility("default"))) extern')
|
Improve consistency of the symbol visibility
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
8 years ago
|
|
|
visibility_cflags += [ '-fvisibility=hidden' ]
|
|
|
|
endif
|
|
|
|
endif
|
|
|
|
|
|
|
|
# The inline keyword is available only for C++ in MSVC.
|
|
|
|
# So we need to use Microsoft specific __inline.
|
|
|
|
if host_system == 'windows'
|
|
|
|
if cc.get_id() == 'msvc'
|
|
|
|
conf.set('inline', '__inline')
|
|
|
|
endif
|
|
|
|
endif
|
|
|
|
|
build: Add Meson build files
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.
8 years ago
|
|
|
# Dependencies
|
|
|
|
dl_dep = cc.find_library('dl', required: false)
|
|
|
|
gl_dep = dependency('gl', required: false)
|
|
|
|
egl_dep = dependency('egl', required: false)
|
|
|
|
|
|
|
|
# Optional dependencies for tests
|
|
|
|
x11_dep = dependency('x11', required: false)
|
|
|
|
|
|
|
|
# GLES v2 and v1 may have pkg-config files, courtesy of downstream
|
|
|
|
# packagers; let's check those first, and fall back to find_library()
|
|
|
|
# if we fail
|
|
|
|
gles2_dep = dependency('glesv2', required: false)
|
|
|
|
if not gles2_dep.found()
|
|
|
|
gles2_dep = cc.find_library('libGLESv2', required: false)
|
|
|
|
endif
|
|
|
|
|
|
|
|
gles1_dep = dependency('glesv1_cm', required: false)
|
|
|
|
if not gles1_dep.found()
|
|
|
|
gles1_dep = cc.find_library('libGLESv1_CM', required: false)
|
|
|
|
endif
|
build: Add Meson build files
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.
8 years ago
|
|
|
|
|
|
|
# On windows, the DLL has to have all of its functions
|
|
|
|
# resolved at link time, so we have to link directly against
|
|
|
|
# opengl32. But that's the only GL provider, anyway.
|
|
|
|
if host_system == 'windows'
|
|
|
|
opengl32_dep = cc.find_library('opengl32', required: true)
|
|
|
|
|
|
|
|
# When building against static libraries, we need to control
|
|
|
|
# the order of the dependencies, and gdi32 provides symbols
|
|
|
|
# needed when using opengl32, like SetPixelFormat and
|
|
|
|
# ChoosePixelFormat. This is mostly a workaround for older
|
|
|
|
# versions of Meson.
|
|
|
|
gdi32_dep = cc.find_library('gdi32', required: true)
|
|
|
|
endif
|
|
|
|
|
|
|
|
# Python
|
|
|
|
python = import('python3').find_python()
|
|
|
|
if not python.found()
|
|
|
|
python = find_program('python', required: true)
|
|
|
|
endif
|
|
|
|
|
|
|
|
# Generates the dispatch tables
|
|
|
|
gen_dispatch_py = files('src/gen_dispatch.py')
|
|
|
|
|
|
|
|
gl_registry = files('registry/gl.xml')
|
|
|
|
egl_registry = files('registry/egl.xml')
|
|
|
|
glx_registry = files('registry/glx.xml')
|
|
|
|
wgl_registry = files('registry/wgl.xml')
|
|
|
|
|
|
|
|
libepoxy_inc = [
|
|
|
|
include_directories('include'),
|
|
|
|
include_directories('src'),
|
|
|
|
]
|
|
|
|
|
|
|
|
subdir('include/epoxy')
|
build: Add Meson build files
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.
8 years ago
|
|
|
subdir('src')
|
|
|
|
|
|
|
|
if get_option('tests')
|
|
|
|
subdir('test')
|
|
|
|
endif
|
|
|
|
|
|
|
|
if get_option('docs')
|
|
|
|
doxygen = find_program('doxygen', required: false)
|
|
|
|
if doxygen.found()
|
|
|
|
subdir('doc')
|
|
|
|
else
|
|
|
|
message('Documentation disabled without doxygen')
|
|
|
|
endif
|
|
|
|
endif
|