* [RFC libdrm 0/2] Replace the build system with meson
@ 2017-03-16 21:25 Dylan Baker
2017-03-16 21:25 ` [RFC libdrm 1/2] Port build system to meson Dylan Baker
` (7 more replies)
0 siblings, 8 replies; 94+ messages in thread
From: Dylan Baker @ 2017-03-16 21:25 UTC (permalink / raw)
To: dri-devel; +Cc: mesa-dev, Dylan Baker
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=true, Size: 10779 bytes --]
Why bother, and why would we want this? │~
First it's written in python, which means the potential developer base
is massive. And it provides a recursive view for humans, but a
non-recursive view for the system. This is the best of both worlds,
humans can organize the build system in a way that makes sense, and the
machine gets a non-recursive build system. It also uses ninja rather
than make, and ninja is faster than make inherently. Meson is also a
simpler syntax than autotools or cmake it's not Turing Complete by
design nor does it expose python, again, by design. This allows meson
itself to be reimplemented in a another language if python becomes a
dead-end or a bottle-neck. It also makes it much easier to understand
what the build system is doing.
What's different about using meson?
Well, apart from a faster builds and less magic in the build system? The
configure flags are different, it uses -D<opt>=<value> more like cmake
than the --enable or --with flags of autotools, although oddly it uses
--prefix and friends when calling meson, but not with mesonconf, there's
a bug opened on this. Meson also doesn't support in-tree builds at all;
all builds are done out of tree. It also doesn't provide a "make dist"
target, fortunately there's this awesome tool called git, and it
provides a "git archive" command that does much the same thing. Did I
mention it's fast?
Here are the performance numbers I see on a 2 core 4 thread SKL, without
initial configuration, and building out of tree (using zsh):
For meson the command line is:
time (meson build -Dmanpages=true && ninja -C build)
For autotools the command line is:
time (mdkir build && cd build && ../autotools && make -j5 -l4)<Paste>
meson (cold ccache): 13.37s user 1.74s system 255% cpu 5.907 total
autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
meson (hot ccache): 2.13s user 0.39s system 154% cpu 1.633 total
autotools (hot ccache): 13.93s user 0.73s system 102% cpu 14.259 total
That's ~4x faster for a cold build and ~10x faster for a hot build.
For a make clean && make style build with a hot cache:
meson: 4.64s user 0.33s system 334% cpu 1.486 total
autotools: 7.93s user 0.32s system 167% cpu 4.920 total
Why bother with libdrm?
It's a simple build system, that could be completely (or mostly
completely) be ported in a very short time, and could serve as a tech
demo for the advantages of using meson to garner feedback for embarking
on a larger project, like mesa (which is what I'm planning to work on
next).
tl;dr
I wrote this as practice for porting Mesa, and figured I might as well
send it out since I wrote it.
It is very likely that neither of these large patches will show up on the
mailing list, but this is available at my github:
https://github.com/dcbaker/libdrm wip/meson
Dylan Baker (2):
Port build system to meson
remove autotools build
.editorconfig | 2 +-
.gitignore | 82 +-----
Makefile.am | 144 +--------
Makefile.sources | 41 +--
README | 21 +-
amdgpu/Makefile.am | 47 +---
amdgpu/Makefile.sources | 15 +-
amdgpu/libdrm_amdgpu.pc.in | 11 +-
amdgpu/meson.build | 57 +++-
autogen.sh | 20 +-
configure.ac | 568 +--------------------------------
etnaviv/Makefile.am | 26 +-
etnaviv/Makefile.sources | 12 +-
etnaviv/libdrm_etnaviv.pc.in | 11 +-
etnaviv/meson.build | 56 +++-
exynos/Makefile.am | 27 +--
exynos/libdrm_exynos.pc.in | 11 +-
exynos/meson.build | 52 +++-
freedreno/Makefile.am | 30 +--
freedreno/Makefile.sources | 26 +-
freedreno/libdrm_freedreno.pc.in | 11 +-
freedreno/meson.build | 72 ++++-
include/drm/meson.build | 48 +++-
intel/Makefile.am | 73 +----
intel/Makefile.sources | 15 +-
intel/intel_bufmgr_gem.c | 8 +-
intel/libdrm_intel.pc.in | 11 +-
intel/meson.build | 55 +++-
libdrm.pc.in | 10 +-
libkms/Makefile.am | 43 +--
libkms/Makefile.sources | 23 +-
libkms/libkms.pc.in | 11 +-
libkms/meson.build | 71 ++++-
m4/.gitignore | 5 +-
man/Makefile.am | 62 +---
man/meson.build | 119 +++++++-
meson.build | 288 ++++++++++++++++-
meson_config.h.in | 24 +-
meson_options.txt | 16 +-
nouveau/Makefile.am | 33 +--
nouveau/Makefile.sources | 9 +-
nouveau/libdrm_nouveau.pc.in | 11 +-
nouveau/meson.build | 63 ++++-
omap/Makefile.am | 24 +-
omap/libdrm_omap.pc.in | 11 +-
omap/meson.build | 48 +++-
radeon/Makefile.am | 47 +---
radeon/Makefile.sources | 21 +-
radeon/libdrm_radeon.pc.in | 11 +-
radeon/meson.build | 62 +++-
tegra/Makefile.am | 25 +-
tegra/libdrm_tegra.pc.in | 11 +-
tegra/meson.build | 50 +++-
tests/Makefile.am | 47 +---
tests/amdgpu/Makefile.am | 29 +--
tests/amdgpu/meson.build | 30 ++-
tests/etnaviv/Makefile.am | 41 +--
tests/etnaviv/meson.build | 49 +++-
tests/exynos/Makefile.am | 47 +---
tests/exynos/meson.build | 43 ++-
tests/kms/Makefile.am | 36 +--
tests/kms/meson.build | 46 +++-
tests/kmstest/Makefile.am | 25 +-
tests/kmstest/meson.build | 28 ++-
tests/meson.build | 87 +++++-
tests/modeprint/Makefile.am | 18 +-
tests/modeprint/meson.build | 27 ++-
tests/modetest/Makefile.am | 24 +-
tests/modetest/Makefile.sources | 6 +-
tests/modetest/meson.build | 27 ++-
tests/nouveau/Makefile.am | 16 +-
tests/nouveau/meson.build | 30 ++-
tests/proptest/Makefile.am | 21 +-
tests/proptest/Makefile.sources | 2 +-
tests/proptest/meson.build | 27 ++-
tests/radeon/Makefile.am | 14 +-
tests/radeon/meson.build | 27 ++-
tests/tegra/Makefile.am | 13 +-
tests/tegra/meson.build | 27 ++-
tests/ttmtest/Makefile.am | 1 +-
tests/ttmtest/src/Makefile.am | 8 +-
tests/util/Makefile.am | 13 +-
tests/util/Makefile.sources | 8 +-
tests/util/meson.build | 35 ++-
tests/vbltest/Makefile.am | 19 +-
tests/vbltest/meson.build | 27 ++-
vc4/Makefile.am | 34 +--
vc4/Makefile.sources | 3 +-
vc4/libdrm_vc4.pc.in | 9 +-
vc4/meson.build | 28 ++-
xf86atomic.h | 4 +-
91 files changed, 1634 insertions(+), 1992 deletions(-)
delete mode 100644 Makefile.am
delete mode 100644 Makefile.sources
delete mode 100644 amdgpu/Makefile.am
delete mode 100644 amdgpu/Makefile.sources
delete mode 100644 amdgpu/libdrm_amdgpu.pc.in
create mode 100644 amdgpu/meson.build
delete mode 100755 autogen.sh
delete mode 100644 configure.ac
delete mode 100644 etnaviv/Makefile.am
delete mode 100644 etnaviv/Makefile.sources
delete mode 100644 etnaviv/libdrm_etnaviv.pc.in
create mode 100644 etnaviv/meson.build
delete mode 100644 exynos/Makefile.am
delete mode 100644 exynos/libdrm_exynos.pc.in
create mode 100644 exynos/meson.build
delete mode 100644 freedreno/Makefile.am
delete mode 100644 freedreno/Makefile.sources
delete mode 100644 freedreno/libdrm_freedreno.pc.in
create mode 100644 freedreno/meson.build
create mode 100644 include/drm/meson.build
delete mode 100644 intel/Makefile.am
delete mode 100644 intel/Makefile.sources
delete mode 100644 intel/libdrm_intel.pc.in
create mode 100644 intel/meson.build
delete mode 100644 libdrm.pc.in
delete mode 100644 libkms/Makefile.am
delete mode 100644 libkms/Makefile.sources
delete mode 100644 libkms/libkms.pc.in
create mode 100644 libkms/meson.build
delete mode 100644 m4/.gitignore
delete mode 100644 man/Makefile.am
create mode 100644 man/meson.build
create mode 100644 meson.build
create mode 100644 meson_config.h.in
create mode 100644 meson_options.txt
delete mode 100644 nouveau/Makefile.am
delete mode 100644 nouveau/Makefile.sources
delete mode 100644 nouveau/libdrm_nouveau.pc.in
create mode 100644 nouveau/meson.build
delete mode 100644 omap/Makefile.am
delete mode 100644 omap/libdrm_omap.pc.in
create mode 100644 omap/meson.build
delete mode 100644 radeon/Makefile.am
delete mode 100644 radeon/Makefile.sources
delete mode 100644 radeon/libdrm_radeon.pc.in
create mode 100644 radeon/meson.build
delete mode 100644 tegra/Makefile.am
delete mode 100644 tegra/libdrm_tegra.pc.in
create mode 100644 tegra/meson.build
delete mode 100644 tests/Makefile.am
delete mode 100644 tests/amdgpu/Makefile.am
create mode 100644 tests/amdgpu/meson.build
delete mode 100644 tests/etnaviv/Makefile.am
create mode 100644 tests/etnaviv/meson.build
delete mode 100644 tests/exynos/Makefile.am
create mode 100644 tests/exynos/meson.build
delete mode 100644 tests/kms/Makefile.am
create mode 100644 tests/kms/meson.build
delete mode 100644 tests/kmstest/Makefile.am
create mode 100644 tests/kmstest/meson.build
create mode 100644 tests/meson.build
delete mode 100644 tests/modeprint/Makefile.am
create mode 100644 tests/modeprint/meson.build
delete mode 100644 tests/modetest/Makefile.am
delete mode 100644 tests/modetest/Makefile.sources
create mode 100644 tests/modetest/meson.build
delete mode 100644 tests/nouveau/Makefile.am
create mode 100644 tests/nouveau/meson.build
delete mode 100644 tests/proptest/Makefile.am
delete mode 100644 tests/proptest/Makefile.sources
create mode 100644 tests/proptest/meson.build
delete mode 100644 tests/radeon/Makefile.am
create mode 100644 tests/radeon/meson.build
delete mode 100644 tests/tegra/Makefile.am
create mode 100644 tests/tegra/meson.build
delete mode 100644 tests/ttmtest/Makefile.am
delete mode 100644 tests/ttmtest/src/Makefile.am
delete mode 100644 tests/util/Makefile.am
delete mode 100644 tests/util/Makefile.sources
create mode 100644 tests/util/meson.build
delete mode 100644 tests/vbltest/Makefile.am
create mode 100644 tests/vbltest/meson.build
delete mode 100644 vc4/Makefile.am
delete mode 100644 vc4/Makefile.sources
delete mode 100644 vc4/libdrm_vc4.pc.in
create mode 100644 vc4/meson.build
base-commit: 19c4cfc54918d361f2535aec16650e9f0be667cd
--
git-series 0.9.1
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* [RFC libdrm 1/2] Port build system to meson
2017-03-16 21:25 [RFC libdrm 0/2] Replace the build system with meson Dylan Baker
@ 2017-03-16 21:25 ` Dylan Baker
2017-03-16 21:25 ` [RFC libdrm 2/2] remove autotools build Dylan Baker
` (6 subsequent siblings)
7 siblings, 0 replies; 94+ messages in thread
From: Dylan Baker @ 2017-03-16 21:25 UTC (permalink / raw)
To: dri-devel; +Cc: mesa-dev, Dylan Baker
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=true, Size: 71274 bytes --]
This is a bit of a tech demo, a bit of a serious port to meson. This
provides almost all of the build system, except for the ability to
install the tests, it doesn't add -lrt for the clock (it's been in core
glibc for some time), has basically no comments, and hasn't been tested
on any platform except Linux (I have cross compiled for arm). It also
relies on unreviewed, unmerged patches to meson for valgrind support
(but will work fine without the patch and without valgrind)
What's not done:
- the install tests flag isn't implemented
- some of the extra data installs aren't implemented
- valgrind is set to "no" rather than "auto". To make valgrind work
correctly you need a patch that's neither reviewed nor landed in
meson, or to implement a hack that might make cross compiling
difficult.
---
.editorconfig | 4 +-
README | 21 +--
amdgpu/meson.build | 57 +++++++-
etnaviv/meson.build | 56 +++++++-
exynos/meson.build | 52 +++++++-
freedreno/meson.build | 72 +++++++++-
include/drm/meson.build | 48 ++++++-
intel/intel_bufmgr_gem.c | 8 +-
intel/meson.build | 55 +++++++-
libkms/meson.build | 71 +++++++++-
man/meson.build | 119 +++++++++++++++-
meson.build | 288 +++++++++++++++++++++++++++++++++++++-
meson_config.h.in | 24 +++-
meson_options.txt | 16 ++-
nouveau/meson.build | 63 ++++++++-
omap/meson.build | 48 ++++++-
radeon/meson.build | 62 ++++++++-
tegra/meson.build | 50 ++++++-
tests/amdgpu/meson.build | 30 ++++-
tests/etnaviv/meson.build | 49 ++++++-
tests/exynos/meson.build | 43 ++++++-
tests/kms/meson.build | 46 ++++++-
tests/kmstest/meson.build | 28 ++++-
tests/meson.build | 87 +++++++++++-
tests/modeprint/meson.build | 27 +++-
tests/modetest/meson.build | 27 +++-
tests/nouveau/meson.build | 30 ++++-
tests/proptest/meson.build | 27 +++-
tests/radeon/meson.build | 27 +++-
tests/tegra/meson.build | 27 +++-
tests/util/meson.build | 35 ++++-
tests/vbltest/meson.build | 27 +++-
vc4/meson.build | 28 ++++-
xf86atomic.h | 4 +-
34 files changed, 1637 insertions(+), 19 deletions(-)
create mode 100644 amdgpu/meson.build
create mode 100644 etnaviv/meson.build
create mode 100644 exynos/meson.build
create mode 100644 freedreno/meson.build
create mode 100644 include/drm/meson.build
create mode 100644 intel/meson.build
create mode 100644 libkms/meson.build
create mode 100644 man/meson.build
create mode 100644 meson.build
create mode 100644 meson_config.h.in
create mode 100644 meson_options.txt
create mode 100644 nouveau/meson.build
create mode 100644 omap/meson.build
create mode 100644 radeon/meson.build
create mode 100644 tegra/meson.build
create mode 100644 tests/amdgpu/meson.build
create mode 100644 tests/etnaviv/meson.build
create mode 100644 tests/exynos/meson.build
create mode 100644 tests/kms/meson.build
create mode 100644 tests/kmstest/meson.build
create mode 100644 tests/meson.build
create mode 100644 tests/modeprint/meson.build
create mode 100644 tests/modetest/meson.build
create mode 100644 tests/nouveau/meson.build
create mode 100644 tests/proptest/meson.build
create mode 100644 tests/radeon/meson.build
create mode 100644 tests/tegra/meson.build
create mode 100644 tests/util/meson.build
create mode 100644 tests/vbltest/meson.build
create mode 100644 vc4/meson.build
diff --git a/.editorconfig b/.editorconfig
index 893b7be..ffc477f 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -17,3 +17,7 @@ indent_style = tab
[*.m4]
indent_style = space
indent_size = 2
+
+[meson.build]
+indent_style = space
+indent_size = 2
diff --git a/README b/README
index 26cab9d..b567d7e 100644
--- a/README
+++ b/README
@@ -15,27 +15,22 @@ with an older kernel.
Compiling
---------
-libdrm is a standard autotools package and follows the normal
-configure, build and install steps. The first step is to configure
-the package, which is done by running the configure shell script:
+libdrm is compiled using meson and ninja. The first step for building for a
+tar-ball or from git is to configure, and set a build directory:
- ./configure
+ meson build
-By default, libdrm will install into the /usr/local/ prefix. If you
-want to install this DRM to replace your system copy, pass
---prefix=/usr and --exec-prefix=/ to configure. If you are building
-libdrm from a git checkout, you first need to run the autogen.sh
-script. You can pass any options to autogen.sh that you would other
-wise pass to configure, or you can just re-run configure with the
-options you need once autogen.sh finishes.
+By default, libdrm will install into the /usr/local/ prefix. If you
+want to install this DRM to replace your system copy, pass
+--prefix=/usr to meson, or -Dprefix=/usr to mesonconf.
Next step is to build libdrm:
- make
+ ninja -C build
and once make finishes successfully, install the package using
- make install
+ ninja install
If you are installing into a system location, you will need to be root
to perform the install step.
diff --git a/amdgpu/meson.build b/amdgpu/meson.build
new file mode 100644
index 0000000..71054df
--- /dev/null
+++ b/amdgpu/meson.build
@@ -0,0 +1,57 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+amdgpu_files = files(
+ 'amdgpu_asic_id.h',
+ 'amdgpu_bo.c',
+ 'amdgpu_cs.c',
+ 'amdgpu_device.c',
+ 'amdgpu_gpu_info.c',
+ 'amdgpu_internal.h',
+ 'amdgpu_vamgr.c',
+ 'util_hash.c',
+ 'util_hash.h',
+ 'util_hash_table.c',
+ 'util_hash_table.h',
+)
+
+libdrm_amdgpu = shared_library(
+ 'drm_amdgpu',
+ amdgpu_files,
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+ dependencies : pthreadstubs_dep,
+ version : '1.0.0',
+ install : true,
+)
+
+install_headers('amdgpu.h', subdir : 'libdrm')
+
+pkg.generate(
+ name : 'libdrm_amdgpu',
+ description : 'Userspace interface to kernel DRM services for amdgpu',
+ version : meson.project_version(),
+ subdirs : ['', 'libdrm'],
+ libraries : [libdrm_amdgpu],
+ requires_private : 'libdrm',
+)
+
+test('amdgpu-symbol-check', find_program('amdgpu-symbol-check'))
diff --git a/etnaviv/meson.build b/etnaviv/meson.build
new file mode 100644
index 0000000..c57152f
--- /dev/null
+++ b/etnaviv/meson.build
@@ -0,0 +1,56 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+etnaviv_files = files(
+ 'etnaviv_device.c',
+ 'etnaviv_gpu.c',
+ 'etnaviv_bo.c',
+ 'etnaviv_bo_cache.c',
+ 'etnaviv_pipe.c',
+ 'etnaviv_cmd_stream.c',
+ 'etnaviv_drm.h',
+ 'etnaviv_priv.h',
+)
+
+etnaviv_include = include_directories('.')
+
+libdrm_etnaviv = shared_library(
+ 'drm_etnaviv',
+ etnaviv_files,
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+ dependencies : [pthreadstubs_dep, valgrind_dep],
+ version : '1.0.0',
+ install : true,
+)
+
+install_headers('etnaviv_drmif.h', subdir : 'libdrm')
+
+pkg.generate(
+ name : 'libdrm_etnaviv',
+ description : 'Userspace interface to etnaviv kernel DRM services',
+ version : meson.project_version(),
+ subdirs : ['', 'libdrm'],
+ libraries : [libdrm_etnaviv],
+ requires_private : 'libdrm',
+)
+
+test('etnaviv-symbol-check', find_program('etnaviv-symbol-check'))
diff --git a/exynos/meson.build b/exynos/meson.build
new file mode 100644
index 0000000..5adc12e
--- /dev/null
+++ b/exynos/meson.build
@@ -0,0 +1,52 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+exynos_files = files(
+ 'exynos_drm.c',
+ 'exynos_fimg2d.c',
+ 'fimg2d_reg.h',
+)
+
+libdrm_exynos = shared_library(
+ 'drm_exynos',
+ exynos_files,
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+ dependencies : [pthreadstubs_dep, valgrind_dep],
+ version : '1.0.0',
+ install : true,
+)
+
+exynos_include = include_directories('.')
+
+install_headers('exynos_drm.h', 'exynos_fimg2d.h', subdir : 'exynos')
+install_headers('exynos_drmif.h', subdir : 'libdrm')
+
+pkg.generate(
+ name : 'libdrm_exynos',
+ description : 'Userspace interface to exynos kernel DRM services',
+ version : '0.7',
+ subdirs : ['', 'libdrm', 'exynos'],
+ libraries : [libdrm_exynos],
+ requires_private : 'libdrm',
+)
+
+test('exynos-symbol-check', find_program('exynos-symbol-check'))
diff --git a/freedreno/meson.build b/freedreno/meson.build
new file mode 100644
index 0000000..ac02a75
--- /dev/null
+++ b/freedreno/meson.build
@@ -0,0 +1,72 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+freedreno_files = files(
+ 'freedreno_device.c',
+ 'freedreno_pipe.c',
+ 'freedreno_priv.h',
+ 'freedreno_ringbuffer.c',
+ 'freedreno_bo.c',
+ 'freedreno_bo_cache.c',
+ 'msm/msm_bo.c',
+ 'msm/msm_device.c',
+ 'msm/msm_drm.h',
+ 'msm/msm_pipe.c',
+ 'msm/msm_priv.h',
+ 'msm/msm_ringbuffer.c',
+)
+
+if get_option('freedreno-kgsl') == 'yes'
+ freedreno_kgsl_files = files(
+ 'kgsl/kgsl_bo.c',
+ 'kgsl/kgsl_device.c',
+ 'kgsl/kgsl_drm.h',
+ 'kgsl/kgsl_pipe.c',
+ 'kgsl/kgsl_priv.h',
+ 'kgsl/kgsl_ringbuffer.c',
+ 'kgsl/msm_kgsl.h',
+ )
+else
+ freedreno_kgsl_files = []
+endif
+
+libdrm_freedreno = shared_library(
+ 'drm_freedreno',
+ [freedreno_files, freedreno_kgsl_files],
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+ dependencies : pthreadstubs_dep,
+ version : '1.0.0',
+ install : true,
+)
+
+install_headers('freedreno_drmif.h', 'freedreno_ringbuffer.h', subdir : 'freedreno')
+
+pkg.generate(
+ name : 'libdrm_freedreno',
+ description : 'Userspace interface to freedreno kernel DRM services',
+ version : meson.project_version(),
+ subdirs : ['', 'libdrm', 'freedreno'],
+ libraries : [libdrm_freedreno],
+ requires_private : 'libdrm',
+)
+
+test('freedreno-symbol-check', find_program('freedreno-symbol-check'))
diff --git a/include/drm/meson.build b/include/drm/meson.build
new file mode 100644
index 0000000..feaf9c8
--- /dev/null
+++ b/include/drm/meson.build
@@ -0,0 +1,48 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+install_headers(
+ 'drm.h',
+ 'drm_fourcc.h',
+ 'drm_mode.h',
+ 'drm_sarea.h',
+ 'i915_drm.h',
+ 'mach64_drm.h',
+ 'mga_drm.h',
+ 'nouveau_drm.h',
+ 'qxl_drm.h',
+ 'r128_drm.h',
+ 'radeon_drm.h',
+ 'amdgpu_drm.h',
+ 'savage_drm.h',
+ 'sis_drm.h',
+ 'tegra_drm.h',
+ 'vc4_drm.h',
+ 'via_drm.h',
+ 'virtgpu_drm.h',
+ subdir : 'libdrm',
+)
+
+if conf_data.get('HAVE_VMWGFX')
+ install_headers(
+ 'vmwgfx_drm.h',
+ subdir : 'libdrm',
+ )
+endif
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index e260f2d..2ba72bb 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1,7 +1,7 @@
/**************************************************************************
*
- * Copyright © 2007 Red Hat Inc.
- * Copyright © 2007-2012 Intel Corporation
+ * Copyright © 2007 Red Hat Inc.
+ * Copyright © 2007-2012 Intel Corporation
* Copyright 2006 Tungsten Graphics, Inc., Bismarck, ND., USA
* All Rights Reserved.
*
@@ -28,7 +28,7 @@
*
**************************************************************************/
/*
- * Authors: Thomas Hellström <thomas-at-tungstengraphics-dot-com>
+ * Authors: Thomas Hellström <thomas-at-tungstengraphics-dot-com>
* Keith Whitwell <keithw-at-tungstengraphics-dot-com>
* Eric Anholt <eric@anholt.net>
* Dave Airlie <airlied@linux.ie>
@@ -1217,7 +1217,7 @@ drm_intel_gem_bo_free(drm_intel_bo *bo)
static void
drm_intel_gem_bo_mark_mmaps_incoherent(drm_intel_bo *bo)
{
-#if HAVE_VALGRIND
+#ifdef HAVE_VALGRIND
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
if (bo_gem->mem_virtual)
diff --git a/intel/meson.build b/intel/meson.build
new file mode 100644
index 0000000..6f455bb
--- /dev/null
+++ b/intel/meson.build
@@ -0,0 +1,55 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+libdrm_intel_files = files(
+ 'intel_bufmgr.c',
+ 'intel_bufmgr_priv.h',
+ 'intel_bufmgr_fake.c',
+ 'intel_bufmgr_gem.c',
+ 'intel_decode.c',
+ 'intel_chipset.h',
+ 'mm.c',
+ 'mm.h',
+ 'uthash.h',
+)
+
+libdrm_intel = shared_library(
+ 'drm_intel',
+ libdrm_intel_files,
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+ dependencies : [pthreadstubs_dep, pciaccess_dep, valgrind_dep],
+ version : '1.0.0',
+ install : true,
+)
+
+install_headers('intel_bufmgr.h', 'intel_aub.h', 'intel_debug.h', subdir : 'libdrm')
+
+pkg.generate(
+ name : 'libdrm_intel',
+ description : 'Userspace interface to intel kernel DRM services',
+ version : meson.project_version(),
+ requires : 'libdrm',
+ subdirs : ['', 'libdrm'],
+ libraries : [libdrm_intel],
+)
+
+test('intel-symbol-check', find_program('intel-symbol-check'))
diff --git a/libkms/meson.build b/libkms/meson.build
new file mode 100644
index 0000000..55e726d
--- /dev/null
+++ b/libkms/meson.build
@@ -0,0 +1,71 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+libkms_files = files(
+ 'internal.h',
+ 'linux.c',
+ 'dumb.c',
+ 'api.c',
+)
+
+libkms_include = include_directories('.')
+
+if conf_data.get('HAVE_VMWGFX', false)
+ libkms_files += files('vmwgfx.c')
+endif
+
+if conf_data.get('HAVE_INTEL', false)
+ libkms_files += files('intel.c')
+endif
+
+if conf_data.get('HAVE_NOUVEAU', false)
+ libkms_files += files('nouveau.c')
+endif
+
+if conf_data.get('HAVE_RADEON', false)
+ libkms_files += files('radeon.c')
+endif
+
+if conf_data.get('HAVE_EXYNOS', false)
+ libkms_files += files('exynos.c')
+endif
+
+libkms = shared_library(
+ 'kms',
+ libkms_files,
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include, include_directories('../exynos')],
+ link_with : libdrm,
+ version : '1.0.0',
+ install : true,
+)
+
+install_headers('libkms.h', subdir : 'libkms')
+
+pkg.generate(
+ name : 'libkms',
+ description : 'Library that abstracts away the different mm interfaces for kernel drivers',
+ version : '1.0.0',
+ requires_private : 'libdrm',
+ subdirs : ['libkms'],
+ libraries : [libkms],
+)
+
+test('kms-symbol-check', find_program('kms-symbol-check'))
diff --git a/man/meson.build b/man/meson.build
new file mode 100644
index 0000000..5108456
--- /dev/null
+++ b/man/meson.build
@@ -0,0 +1,119 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+xsltproc = find_program('xsltproc')
+sed = find_program('sed')
+
+stylesheet_url = 'http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl'
+ret = run_command(xsltproc, '--nonet', stylesheet_url)
+if ret.returncode() != 0
+ error('Cannot build man pages without docbook-xml')
+endif
+
+xsltproc_args = [xsltproc, '-o', '@OUTPUT@',
+ '--stringparam', 'man.authors.section.enabled', '0',
+ '--stringparam', 'man.copyright.section.enabled', '0',
+ '--stringparam', 'funcsynopsis.style', 'ansi',
+ '--stringparam', 'man.output.quietly', '1',
+ '--noout', stylesheet_url, '@INPUT@']
+
+# TODO: https://github.com/mesonbuild/meson/issues/1364
+# This issue is about creating reusable custom_target templates, which would
+# simplify the following custom_targets considerably.
+drm_avail_man = custom_target(
+ 'drmAvailable.3',
+ input : 'drmAvailable.xml',
+ output : '@BASENAME@.3',
+ command : xsltproc_args,
+ install : true,
+ install_dir : 'usr/share/man/man3',
+)
+
+drm_handleevent_man = custom_target(
+ 'drmHandleEvent.3',
+ input : 'drmHandleEvent.xml',
+ output : '@BASENAME@.3',
+ command : xsltproc_args,
+ install : true,
+ install_dir : 'usr/share/man/man3',
+)
+
+drm_modegetresources_man = custom_target(
+ 'drmModeGetResources.3',
+ input : 'drmModeGetResources.xml',
+ output : '@BASENAME@.3',
+ command : xsltproc_args,
+ install : true,
+ install_dir : 'usr/share/man/man3',
+)
+
+drm_man = custom_target(
+ 'drm.7',
+ input : 'drm.xml',
+ output : '@BASENAME@.7',
+ command : xsltproc_args,
+ install : true,
+ install_dir : 'usr/share/man/man7',
+)
+
+drm_kms_man = custom_target(
+ 'kms.7',
+ input : 'drm-kms.xml',
+ output : '@BASENAME@.7',
+ command : xsltproc_args,
+ install : true,
+ install_dir : 'usr/share/man/man7',
+)
+
+drm_memory_man = custom_target(
+ 'memory.7',
+ input : 'drm-memory.xml',
+ output : '@BASENAME@.7',
+ command : xsltproc_args,
+ install : true,
+ install_dir : 'usr/share/man/man7',
+)
+
+drm_mm = custom_target(
+ 'mm.7',
+ input : 'drm-memory.xml',
+ output : 'drm-mm.7',
+ command : xsltproc_args,
+ install : true,
+ install_dir : 'usr/share/man/man7',
+)
+
+drm_gem = custom_target(
+ 'gem.7',
+ input : 'drm-memory.xml',
+ output : 'drm-gem.7',
+ command : xsltproc_args,
+ install : true,
+ install_dir : 'usr/share/man/man7',
+)
+
+drm_gem = custom_target(
+ 'ttm.7',
+ input : 'drm-memory.xml',
+ output : 'drm-ttm.7',
+ command : xsltproc_args,
+ install : true,
+ install_dir : 'usr/share/man/man7',
+)
diff --git a/meson.build b/meson.build
new file mode 100644
index 0000000..f8a75a0
--- /dev/null
+++ b/meson.build
@@ -0,0 +1,288 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+project('libdrm', 'c', version : '2.4.76-dev', default_options : ['-std=c99'])
+
+pkg = import('pkgconfig')
+
+conf_data = configuration_data()
+
+global_warn_flags = []
+
+atomic_dep = []
+cunit_dep = []
+pciaccess_dep = []
+valgrind_dep = []
+pthreadstubs_dep = dependency('pthread-stubs') # TODO: is this always required?
+cairo_dep = dependency('cairo', required : false)
+if cairo_dep.found()
+ conf_data.set('HAVE_CAIRO', true)
+endif
+thread_dep = dependency('threads')
+
+system = host_machine.system()
+if system.startswith('linux')
+ add_project_arguments('-D_GNU_SOURCE', language : 'c')
+endif
+
+cc = meson.get_compiler('c')
+
+# TODO: resolve whether we need -lrt
+cc.find_library('m')
+if cc.has_header('sys/sysctl.h')
+ conf_data.set('HAVE_SYS_SYSCTL_H', true)
+endif
+if cc.has_header('sys/select.h')
+ conf_data.set('HAVE_SYS_SELECT_H', true)
+endif
+if cc.has_header('alloca.h')
+ conf_data.set('HAVE_ALLOCA_H', true)
+endif
+if cc.has_function('major', prefix : '#include <sys/sysmacros.h>')
+ conf_data.set('MAJOR_IN_SYSMACROS', true)
+elif cc.has_function('major', prefix : '#include <sys/mkdev.h>')
+ conf_data.set('MAJOR_IN_MKDEV', true)
+endif
+if cc.has_function('open_memstream')
+ conf_data.set('HAVE_OPEN_MEMSTREAM', true)
+endif
+
+if cc.compiles('''int foo_hidden(void) __attribute__((visibility("hidden")));''')
+ conf_data.set('HAVE_ATTRIBUTE_VISIBILITY', true)
+endif
+
+# TODO: copy comment from configure.ac
+global_warn_flag_opts = [
+ '-Wall', '-Wextra', '-Wsign-compare',
+ '-Werror-implicit-function-declaration', '-Wpointer-arith',
+ '-Wwrite-strings', '-Wstrict-prototypes', '-Wmissing-prototypes',
+ '-Wmissing-format-attribute', '-Wnested-externs', '-Wpacked',
+ '-Wswitch-enum', '-Wmissing-format-attribute', '-Wstrict-aliasing=2',
+ '-Winit-self', '-Wdeclaration-after-statement', '-Wold-style-definition',
+ '-Wno-unused-parameter', '-Wno-attributes', '-Wno-long-long', '-Winline',
+ '-Wshadow', '-Wno-missing-field-initializers',
+]
+foreach f : global_warn_flag_opts
+ if cc.has_argument(f)
+ global_warn_flags += f
+ endif
+endforeach
+
+# Check for atomic intrinsics
+if cc.compiles('''
+ int atomic_add(int *i) { return __sync_add_and_fetch (i, 1); }
+ int atomic_cmpxchg(int *i, int j, int k) { return __sync_val_compare_and_swap (i, j, k); }
+ ''')
+ conf_data.set('HAVE_LIBDRM_ATOMIC_PRIMITIVES', true)
+elif (system.startswith('solaris') or system.startswith('netbsd')
+ and cc.has_function('atomic_cas_uint'))
+ if not cc.has_header('sys/atomic.h')
+ error('wat?')
+ endif
+else
+ atomic_dep = dependency('atomic_ops')
+ conf_data.set('HAVE_LIB_ATOMIC_OPS', true)
+endif
+
+if get_option('udev') == 'yes'
+ dependency('udev')
+ conf_data.set('UDEV', true)
+endif
+
+cpu = host_machine.cpu_family()
+if get_option('intel') != 'no'
+ if cpu == 'x86' or cpu == 'x86_64'
+ pciaccess_dep = dependency('pciaccess', version : '>=0.10')
+ conf_data.set('HAVE_INTEL', true)
+ endif
+endif
+if get_option('radeon') != 'no'
+ conf_data.set('HAVE_RADEON', true)
+endif
+if get_option('amdgpu') != 'no'
+ conf_data.set('HAVE_AMDGPU', true)
+ cunit_dep = dependency('cunit', version : '>=2.1', required : false)
+ if cunit_dep.found()
+ conf_data.set('HAVE_CUNIT', true)
+ endif
+endif
+if get_option('nouveau') != 'no'
+ conf_data.set('HAVE_NOUVEAU', true)
+ dl_lib = cc.find_library('dl')
+ if dl_lib.found()
+ dl_dep = declare_dependency(link_args : '-ldl')
+ else
+ error('nouveau tests require dlopen')
+ endif
+endif
+if get_option('freedreno') != 'no'
+ if cpu == 'arm'
+ conf_data.set('HAVE_FREEDRENO', true)
+ if get_option('freedreno-kgsl') == 'yes'
+ conf_data.set('HAVE_FREEDRENO_KGSL', true)
+ endif
+ endif
+endif
+if get_option('vc4') != 'no'
+ if cpu == 'arm'
+ conf_data.set('HAVE_VC4', true)
+ endif
+endif
+if get_option('vmwgfx') == 'yes'
+ conf_data.set('HAVE_VMWGFX', true)
+endif
+if get_option('omap-experimental-api') == 'yes'
+ if cpu == 'arm'
+ conf_data.set('HAVE_OMAP', true)
+ endif
+endif
+if get_option('exynos-experimental-api') == 'yes'
+ if cpu == 'arm'
+ conf_data.set('HAVE_EXYNOS', true)
+ endif
+endif
+if get_option('tegra-experimental-api') == 'yes'
+ if cpu == 'arm'
+ conf_data.set('HAVE_TEGRA', true)
+ endif
+endif
+if get_option('etnaviv-experimental-api') == 'yes'
+ if cpu == 'arm'
+ conf_data.set('HAVE_ETNAVIV', true)
+ endif
+endif
+
+if get_option('libkms') == 'auto'
+ if (system.startswith('linux') or
+ system.startswith('freebsd') or
+ system.startswith('dragonfly') or
+ (system.startswith('kfreebsd') and system.endswith('-gnu')))
+ conf_data.set('HAVE_LIBKMS', true)
+ elif get_option('libkms') == 'no'
+ conf_data.set('HAVE_LIBKMS', false)
+ endif
+elif get_option('libkms') == 'yes'
+ conf_data.set('HAVE_LIBKMS', true)
+else
+ conf_data.set('HAVE_LIBKMS', false)
+endif
+
+# TODO: https://github.com/mesonbuild/meson/issues/826
+# This only works with a dev build of meson
+if get_option('valgrind') != 'no'
+ valgrind_dep = dependency(
+ 'valgrind',
+ headers_only : true,
+ required : get_option('valgrind') == 'yes'
+ )
+ if valgrind_dep.found()
+ conf_data.set('HAVE_VALGRIND', true)
+ endif
+endif
+
+config_h = configure_file(
+ input : 'meson_config.h.in',
+ output : 'config.h',
+ configuration : conf_data,
+)
+add_project_arguments('-DHAVE_CONFIG_H', language : 'c')
+
+libdrm_files = files(
+ 'xf86drm.c',
+ 'xf86drmHash.c',
+ 'xf86drmHash.h',
+ 'xf86drmRandom.c',
+ 'xf86drmRandom.h',
+ 'xf86drmSL.c',
+ 'xf86drmMode.c',
+ 'xf86atomic.h',
+ 'libdrm_macros.h',
+ 'libdrm_lists.h',
+ 'util_double_list.h',
+ 'util_math.h',
+)
+
+drm_include = include_directories('include/drm')
+base_include = include_directories('.')
+
+libdrm = shared_library(
+ 'drm',
+ libdrm_files,
+ include_directories : [base_include, drm_include],
+ dependencies : valgrind_dep,
+ c_args : global_warn_flags,
+ link_args : '-lm',
+ version : '2.4.0',
+ install : true,
+)
+
+install_headers(
+ 'libsync.h',
+ 'xf86drm.h',
+ 'xf86drmMode.h',
+)
+
+pkg.generate(
+ name : 'libdrm',
+ filebase : 'libdrm',
+ description : 'Userspace interface to kernel DRM services',
+ version : meson.project_version(),
+ libraries : [libdrm],
+ subdirs : ['', 'libdrm'],
+)
+
+subdir('include/drm')
+if conf_data.get('HAVE_LIBKMS', false)
+ subdir('libkms')
+endif
+if conf_data.get('HAVE_INTEL', false)
+ subdir('intel')
+endif
+if conf_data.get('HAVE_NOUVEAU', false)
+ subdir('nouveau')
+endif
+if conf_data.get('HAVE_RADEON', false)
+ subdir('radeon')
+endif
+if conf_data.get('HAVE_AMDGPU', false)
+ subdir('amdgpu')
+endif
+if conf_data.get('HAVE_OMAP', false)
+ subdir('omap')
+endif
+if conf_data.get('HAVE_EXYNOS', false)
+ subdir('exynos')
+endif
+if conf_data.get('HAVE_FREEDRENO', false)
+ subdir('freedreno')
+endif
+if conf_data.get('HAVE_TEGRA', false)
+ subdir('tegra')
+endif
+if conf_data.get('HAVE_VC4', false)
+ subdir('vc4')
+endif
+if conf_data.get('HAVE_ETNAVIV', false)
+ subdir('etnaviv')
+endif
+subdir('tests')
+if get_option('manpages')
+ subdir('man')
+endif
diff --git a/meson_config.h.in b/meson_config.h.in
new file mode 100644
index 0000000..a45723c
--- /dev/null
+++ b/meson_config.h.in
@@ -0,0 +1,24 @@
+#mesondefine HAVE_LIBDRM_ATOMIC_PRIMITIVES
+#mesondefine HAVE_LIB_ATOMIC_OPS
+#mesondefine HAVE_INTEL
+#mesondefine HAVE_RADEON
+#mesondefine HAVE_AMDGPU
+#mesondefine HAVE_NOUVEAU
+#mesondefine HAVE_FREEDRENO
+#mesondefine HAVE_FREEDRENO_KGSL
+#mesondefine HAVE_VC4
+#mesondefine HAVE_OMAP
+#mesondefine HAVE_EXYNOS
+#mesondefine HAVE_TEGRA
+#mesondefine HAVE_ETNAVIV
+#mesondefine HAVE_LIBKMS
+#mesondefine HAVE_SYS_SYSCTL_H
+#mesondefine HAVE_SYS_SELECT_H
+#mesondefine HAVE_VALGRIND
+#mesondefine HAVE_OPEN_MEMSTREAM
+#mesondefine HAVE_CAIRO
+#mesondefine UDEV
+#mesondefine HAVE_ATTRIBUTE_VISIBILITY
+#mesondefine HAVE_ALLOCA_H
+#mesondefine MAJOR_IN_SYSMACROS
+#mesondefine MAJOR_IN_MKDEV
diff --git a/meson_options.txt b/meson_options.txt
new file mode 100644
index 0000000..d1d7190
--- /dev/null
+++ b/meson_options.txt
@@ -0,0 +1,16 @@
+option('intel', type : 'combo', choices : ['auto', 'yes', 'no'], value : 'auto')
+option('radeon', type : 'combo', choices : ['auto', 'yes', 'no'], value : 'auto')
+option('amdgpu', type : 'combo', choices : ['auto', 'yes', 'no'], value : 'auto')
+option('nouveau', type : 'combo', choices : ['auto', 'yes', 'no'], value : 'auto')
+option('vmwgfx', type : 'combo', choices : ['yes', 'no', ], value : 'yes')
+option('freedreno', type : 'combo', choices : ['auto', 'yes', 'no'], value : 'auto')
+option('freedreno-kgsl', type : 'combo', choices : ['yes', 'no', ], value : 'no')
+option('vc4', type : 'combo', choices : ['auto', 'yes', 'no'], value : 'auto')
+option('omap-experimental-api', type : 'combo', choices : ['auto', 'yes', 'no'], value : 'no')
+option('exynos-experimental-api', type : 'combo', choices : ['auto', 'yes', 'no'], value : 'no')
+option('tegra-experimental-api', type : 'combo', choices : ['auto', 'yes', 'no'], value : 'no')
+option('etnaviv-experimental-api', type : 'combo', choices : ['auto', 'yes', 'no'], value : 'no')
+option('libkms', type : 'combo', choices : ['auto', 'yes', 'no'], value : 'auto')
+option('valgrind', type : 'combo', choices : ['auto', 'yes', 'no'], value : 'no')
+option('udev', type : 'combo', choices : ['yes', 'no', ], value : 'no')
+option('manpages', type : 'boolean', value : false)
diff --git a/nouveau/meson.build b/nouveau/meson.build
new file mode 100644
index 0000000..6101b3c
--- /dev/null
+++ b/nouveau/meson.build
@@ -0,0 +1,63 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+nouveau_files = files(
+ 'nouveau.c',
+ 'pushbuf.c',
+ 'bufctx.c',
+ 'abi16.c',
+ 'private.h',
+)
+
+nouveau_include = include_directories('.')
+
+libdrm_nouveau = shared_library(
+ 'drm_nouveau',
+ nouveau_files,
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+ dependencies : pthreadstubs_dep,
+ version : '2.0.0',
+ install : true,
+)
+
+install_headers('nouveau.h', subdir : 'libdrm/nouveau')
+install_headers(
+ 'nvif/class.h',
+ 'nvif/cl0080.h',
+ 'nvif/cl9097.h',
+ 'nvif/if0002.h',
+ 'nvif/if0003.h',
+ 'nvif/ioctl.h',
+ 'nvif/unpack.h',
+ subdir : 'nouveau/nvif',
+)
+
+pkg.generate(
+ name : 'libdrm_nouveau',
+ description : 'Userspace interface to nouveau kernel DRM services',
+ version : meson.project_version(),
+ subdirs : ['', 'libdrm'],
+ libraries : [libdrm_nouveau],
+ requires_private : 'libdrm',
+)
+
+test('nouveau-symbol-check', find_program('nouveau-symbol-check'))
diff --git a/omap/meson.build b/omap/meson.build
new file mode 100644
index 0000000..83f3003
--- /dev/null
+++ b/omap/meson.build
@@ -0,0 +1,48 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+omap_files = files(
+ 'omap_drm.c',
+)
+
+libdrm_omap = shared_library(
+ 'drm_omap',
+ omap_files,
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+ dependencies : [pthreadstubs_dep, valgrind_dep],
+ version : '1.0.0',
+ install : true,
+)
+
+install_headers('omap_drm.h', subdir : 'omap')
+install_headers('omap_drmif.h', subdir : 'libdrm')
+
+pkg.generate(
+ name : 'libdrm_omap',
+ description : 'Userspace interface to omap kernel DRM services',
+ version : '0.6',
+ subdirs : ['', 'libdrm', 'omap'],
+ libraries : [libdrm_omap],
+ requires_private : 'libdrm',
+)
+
+test('omap-symbol-check', find_program('omap-symbol-check'))
diff --git a/radeon/meson.build b/radeon/meson.build
new file mode 100644
index 0000000..b1630fc
--- /dev/null
+++ b/radeon/meson.build
@@ -0,0 +1,62 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+radeon_files = files(
+ 'radeon_bo_gem.c',
+ 'radeon_cs_gem.c',
+ 'radeon_cs_space.c',
+ 'radeon_bo.c',
+ 'radeon_cs.c',
+ 'radeon_surface.c',
+)
+
+libdrm_radeon = shared_library(
+ 'drm_radeon',
+ radeon_files,
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+ dependencies : pthreadstubs_dep,
+ version : '1.0.1',
+ install : true,
+)
+
+install_headers(
+ 'radeon_bo.h',
+ 'radeon_cs.h',
+ 'radeon_surface.h',
+ 'radeon_bo_gem.h',
+ 'radeon_cs_gem.h',
+ 'radeon_bo_int.h',
+ 'radeon_cs_int.h',
+ 'r600_pci_ids.h',
+ subdir : 'libdrm'
+)
+
+pkg.generate(
+ name : 'libdrm_radeon',
+ description : 'Userspace interface to kernel DRM services for radeon',
+ version : meson.project_version(),
+ subdirs : ['', 'libdrm'],
+ libraries : [libdrm_radeon],
+ requires_private : 'libdrm',
+)
+
+test('radeon-symbol-check', find_program('radeon-symbol-check'))
diff --git a/tegra/meson.build b/tegra/meson.build
new file mode 100644
index 0000000..4a90fc1
--- /dev/null
+++ b/tegra/meson.build
@@ -0,0 +1,50 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+tegra_files = files(
+ 'private.h',
+ 'tegra.c',
+)
+
+libdrm_tegra = shared_library(
+ 'drm_tegra',
+ tegra_files,
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+ dependencies : [pthreadstubs_dep, valgrind_dep],
+ version : '1.0.0',
+ install : true,
+)
+
+tegra_include = include_directories('.')
+
+install_headers('tegra.h', subdir : 'libdrm')
+
+pkg.generate(
+ name : 'libdrm_tegra',
+ description : 'Userspace interface to Tegra kernel DRM services',
+ version : meson.project_version(),
+ subdirs : ['', 'libdrm'],
+ libraries : [libdrm_tegra],
+ requires_private : 'libdrm',
+)
+
+test('tegra-symbol-check', find_program('tegra-symbol-check'))
diff --git a/tests/amdgpu/meson.build b/tests/amdgpu/meson.build
new file mode 100644
index 0000000..86bd516
--- /dev/null
+++ b/tests/amdgpu/meson.build
@@ -0,0 +1,30 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+if conf_data.get('HAVE_CUNIT', false)
+ amdgpu_test = executable(
+ 'amdgpu_test',
+ ['amdgpu_test.c', 'amdgpu_test.h', 'basic_tests.c', 'bo_tests.c',
+ 'cs_tests.c', 'uvd_messages.h', 'vce_tests.c', 'vce_ib.h', 'frame.h'],
+ include_directories : [base_include, include_directories('../../amdgpu'), drm_include],
+ dependencies : cunit_dep,
+ link_with : [libdrm, libdrm_amdgpu],
+ )
+endif
diff --git a/tests/etnaviv/meson.build b/tests/etnaviv/meson.build
new file mode 100644
index 0000000..cb75c03
--- /dev/null
+++ b/tests/etnaviv/meson.build
@@ -0,0 +1,49 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+if conf_data.get('HAVE_LIBKMS', false)
+ test_etnaviv_2d = executable(
+ 'etnaviv_2d_test',
+ ['cmdstream.xml.h', 'etnaviv_2d_test.c', 'state.xml.h', 'state_2d.xml.h',
+ 'write_bmp.c', 'write_bmp.h'],
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include, etnaviv_include],
+ link_with : [libdrm, libdrm_etnaviv],
+ dependencies : thread_dep
+ )
+endif
+
+test_etnaviv_cmd_stream = executable(
+ 'etnaviv_cmd_stream_test',
+ 'etnaviv_cmd_stream_test.c',
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include, etnaviv_include],
+ link_with : [libdrm_etnaviv],
+ dependencies : thread_dep
+)
+
+test_etnaviv_bo_cache = executable(
+ 'etnaviv_bo_cache_test',
+ 'etnaviv_bo_cache_test.c',
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include, etnaviv_include],
+ link_with : [libdrm, libdrm_etnaviv],
+ dependencies : thread_dep
+)
diff --git a/tests/exynos/meson.build b/tests/exynos/meson.build
new file mode 100644
index 0000000..b216e71
--- /dev/null
+++ b/tests/exynos/meson.build
@@ -0,0 +1,43 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+test_exynos_fimg2d_perf = executable(
+ 'exynos_fimg2d_perf',
+ 'exynos_fim2d_perf.c',
+ include_directories : [base_include, libkms_include, exynos_include, drm_include],
+ link_with : [libdrm, libdrm_exynos],
+)
+
+test_exynos_fimg2d_event = executable(
+ 'exynos_fimg2d_event',
+ 'exynos_fimg2d_event.c',
+ include_directories : [base_include, kms_include, exynos_include, drm_include],
+ link_with : [libdrm, libdrm_exynos],
+)
+
+if conf_data.get('HAVE_LIBKMS', false):
+ test_exynos_fimg2d_test = executable(
+ 'exynos_fimg2d_test',
+ 'exynos_fimg2d_test.c',
+ dependencies : test_util_dep,
+ include_directories : [base_include, kms_include, exynos_include, drm_include],
+ link_with : [libdrm, libdrm_exynos],
+ )
+endif
diff --git a/tests/kms/meson.build b/tests/kms/meson.build
new file mode 100644
index 0000000..430bdce
--- /dev/null
+++ b/tests/kms/meson.build
@@ -0,0 +1,46 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+kms_test_common_files = files(
+ 'libkms-test.h',
+ 'libkms-test-crtc.c',
+ 'libkms-test-device.c',
+ 'libkms-test-framebuffer.c',
+ 'libkms-test-plane.c',
+ 'libkms-test-screen.c',
+)
+
+test_kms_steal_crtc = executable(
+ 'kms-steal-crtc',
+ [kms_test_common_files, 'kms-steal-crtc.c'],
+ c_args : global_warn_flags,
+ include_directories : drm_include,
+ dependencies : test_util_dep,
+ link_with : libdrm,
+)
+
+test_kms_universal_planes = executable(
+ 'kms-universal-planes',
+ [kms_test_common_files, 'kms-universal-planes.c'],
+ c_args : global_warn_flags,
+ dependencies : cairo_dep,
+ include_directories : [base_include, test_include, drm_include],
+ link_with : libdrm,
+)
diff --git a/tests/kmstest/meson.build b/tests/kmstest/meson.build
new file mode 100644
index 0000000..e4cfa13
--- /dev/null
+++ b/tests/kmstest/meson.build
@@ -0,0 +1,28 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+kmstest = executable(
+ 'kmstest',
+ 'main.c',
+ include_directories : libkms_include,
+ dependencies : test_util_dep,
+ link_with : [libkms, libdrm],
+ c_args : global_warn_flags,
+)
diff --git a/tests/meson.build b/tests/meson.build
new file mode 100644
index 0000000..1989ae1
--- /dev/null
+++ b/tests/meson.build
@@ -0,0 +1,87 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+test_drmsl = executable(
+ 'drmsl',
+ 'drmsl.c',
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+)
+
+test_hash = executable(
+ 'hash',
+ 'hash.c',
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+)
+
+test_random = executable(
+ 'random',
+ 'random.c',
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+)
+
+test_drmdevice = executable(
+ 'drmdevice',
+ 'drmdevice.c',
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+)
+
+test('drmsl', test_drmsl)
+test('hash', test_hash)
+# XXX: This test never seems to finish
+#test('random', test_random)
+test('drmdevice', test_drmdevice)
+
+test_include = include_directories('.')
+
+subdir('util')
+subdir('kms')
+subdir('modeprint')
+subdir('proptest')
+subdir('modetest')
+subdir('vbltest')
+if conf_data.get('HAVE_LIBKMS', false)
+ subdir('kmstest')
+endif
+if conf_data.get('HAVE_RADEON', false)
+ subdir('radeon')
+endif
+if conf_data.get('HAVE_AMDGPU', false) and conf_data.get('HAVE_CUNIT', false)
+ subdir('amdgpu')
+endif
+if conf_data.get('have_exynos', false)
+ subdir('exynos')
+endif
+if conf_data.get('HAVE_TEGRA', false)
+ subdir('tegra')
+endif
+if conf_data.get('HAVE_ETNAVIV', false)
+ subdir('etnaviv')
+endif
+if conf_data.get('HAVE_NOUVEAU', false)
+ subdir('nouveau')
+endif
diff --git a/tests/modeprint/meson.build b/tests/modeprint/meson.build
new file mode 100644
index 0000000..ea8d0de
--- /dev/null
+++ b/tests/modeprint/meson.build
@@ -0,0 +1,27 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+test_modeprint = executable(
+ 'modeprint',
+ 'modeprint.c',
+ include_directories : [drm_include, test_include, base_include],
+ link_with : libdrm,
+ c_args : global_warn_flags,
+)
diff --git a/tests/modetest/meson.build b/tests/modetest/meson.build
new file mode 100644
index 0000000..6579a2f
--- /dev/null
+++ b/tests/modetest/meson.build
@@ -0,0 +1,27 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+modetest = executable(
+ 'modetest',
+ ['buffers.c', 'buffers.h', 'cursor.c', 'cursor.h', 'modetest.c'],
+ c_args : [global_warn_flags, '-Wno-pointer-arith'],
+ dependencies : [test_util_dep, thread_dep],
+ link_with : libdrm,
+)
diff --git a/tests/nouveau/meson.build b/tests/nouveau/meson.build
new file mode 100644
index 0000000..bd87222
--- /dev/null
+++ b/tests/nouveau/meson.build
@@ -0,0 +1,30 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+test_nouveau_threaded = executable(
+ 'threaded',
+ 'threaded.c',
+ dependencies : [thread_dep, dl_dep],
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include, nouveau_include],
+ link_with : [libdrm_nouveau, libdrm],
+)
+
+test('nouveau-threaded', test_nouveau_threaded)
diff --git a/tests/proptest/meson.build b/tests/proptest/meson.build
new file mode 100644
index 0000000..9d20cb9
--- /dev/null
+++ b/tests/proptest/meson.build
@@ -0,0 +1,27 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+test_proptest = executable(
+ 'proptest',
+ 'proptest.c',
+ c_args : global_warn_flags,
+ dependencies : [test_util_dep],
+ link_with : libdrm,
+)
diff --git a/tests/radeon/meson.build b/tests/radeon/meson.build
new file mode 100644
index 0000000..8cc58cf
--- /dev/null
+++ b/tests/radeon/meson.build
@@ -0,0 +1,27 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+radeon_ttm = executable(
+ 'radeon_ttm',
+ ['rbo.c', 'rbo.h', 'radeon_ttm.c'],
+ c_args : global_warn_flags,
+ include_directories : [base_include, drm_include],
+ link_with : libdrm,
+)
diff --git a/tests/tegra/meson.build b/tests/tegra/meson.build
new file mode 100644
index 0000000..dd3e15a
--- /dev/null
+++ b/tests/tegra/meson.build
@@ -0,0 +1,27 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+test_tegra_openclose = executable(
+ 'openclose',
+ 'openclose.c',
+ c_args : global_warn_flags,
+ include_directories : [base_include, tegra_include, drm_include],
+ link_with : [libdrm, libdrm_tegra],
+)
diff --git a/tests/util/meson.build b/tests/util/meson.build
new file mode 100644
index 0000000..0c12112
--- /dev/null
+++ b/tests/util/meson.build
@@ -0,0 +1,35 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+test_util_files = files(
+ 'common.h',
+ 'format.c',
+ 'format.h',
+ 'kms.c',
+ 'kms.h',
+ 'pattern.c',
+ 'pattern.h',
+)
+
+test_util_dep = declare_dependency(
+ sources : test_util_files,
+ include_directories : [base_include, drm_include, test_include],
+ dependencies : cairo_dep,
+)
diff --git a/tests/vbltest/meson.build b/tests/vbltest/meson.build
new file mode 100644
index 0000000..b454b6d
--- /dev/null
+++ b/tests/vbltest/meson.build
@@ -0,0 +1,27 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+vbltest = executable(
+ 'vbltest',
+ 'vbltest.c',
+ c_args : global_warn_flags,
+ dependencies : test_util_dep,
+ link_with : libdrm,
+)
diff --git a/vc4/meson.build b/vc4/meson.build
new file mode 100644
index 0000000..a0d9e4f
--- /dev/null
+++ b/vc4/meson.build
@@ -0,0 +1,28 @@
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+install_headers('vc4_packet.h', 'vc4_qpu_defines.h', subdir : 'libdrm')
+
+pkg.generate(
+ name : 'libdrm_vc4',
+ description : 'Userspace interface to vc4 kernel DRM services',
+ version : meson.project_version(),
+ requires_private : 'libdrm',
+)
diff --git a/xf86atomic.h b/xf86atomic.h
index 922b37d..57ccdfd 100644
--- a/xf86atomic.h
+++ b/xf86atomic.h
@@ -38,7 +38,7 @@
#include "config.h"
#endif
-#if HAVE_LIBDRM_ATOMIC_PRIMITIVES
+#ifdef HAVE_LIBDRM_ATOMIC_PRIMITIVES
#define HAS_ATOMIC_OPS 1
@@ -57,7 +57,7 @@ typedef struct {
#endif
-#if HAVE_LIB_ATOMIC_OPS
+#ifdef HAVE_LIB_ATOMIC_OPS
#include <atomic_ops.h>
#define HAS_ATOMIC_OPS 1
--
git-series 0.9.1
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [RFC libdrm 2/2] remove autotools build
2017-03-16 21:25 [RFC libdrm 0/2] Replace the build system with meson Dylan Baker
2017-03-16 21:25 ` [RFC libdrm 1/2] Port build system to meson Dylan Baker
@ 2017-03-16 21:25 ` Dylan Baker
2017-03-16 21:32 ` [RFC libdrm 0/2] Replace the build system with meson Ilia Mirkin
` (5 subsequent siblings)
7 siblings, 0 replies; 94+ messages in thread
From: Dylan Baker @ 2017-03-16 21:25 UTC (permalink / raw)
To: dri-devel; +Cc: mesa-dev, Dylan Baker
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=true, Size: 67871 bytes --]
This is mostly to demonstrate all of the code that would be deleted by
removing the autotools build.
This is *not* ready to land, since it deletes some files used by the android
build (Makefile.sources).
---
.editorconfig | 4 +-
.gitignore | 82 +-----
Makefile.am | 144 +--------
Makefile.sources | 41 +--
amdgpu/Makefile.am | 47 +---
amdgpu/Makefile.sources | 15 +-
amdgpu/libdrm_amdgpu.pc.in | 11 +-
autogen.sh | 20 +-
configure.ac | 568 +--------------------------------
etnaviv/Makefile.am | 26 +-
etnaviv/Makefile.sources | 12 +-
etnaviv/libdrm_etnaviv.pc.in | 11 +-
exynos/Makefile.am | 27 +--
exynos/libdrm_exynos.pc.in | 11 +-
freedreno/Makefile.am | 30 +--
freedreno/Makefile.sources | 26 +-
freedreno/libdrm_freedreno.pc.in | 11 +-
intel/Makefile.am | 73 +----
intel/Makefile.sources | 15 +-
intel/libdrm_intel.pc.in | 11 +-
libdrm.pc.in | 10 +-
libkms/Makefile.am | 43 +--
libkms/Makefile.sources | 23 +-
libkms/libkms.pc.in | 11 +-
m4/.gitignore | 5 +-
man/Makefile.am | 62 +---
nouveau/Makefile.am | 33 +--
nouveau/Makefile.sources | 9 +-
nouveau/libdrm_nouveau.pc.in | 11 +-
omap/Makefile.am | 24 +-
omap/libdrm_omap.pc.in | 11 +-
radeon/Makefile.am | 47 +---
radeon/Makefile.sources | 21 +-
radeon/libdrm_radeon.pc.in | 11 +-
tegra/Makefile.am | 25 +-
tegra/libdrm_tegra.pc.in | 11 +-
tests/Makefile.am | 47 +---
tests/amdgpu/Makefile.am | 29 +--
tests/etnaviv/Makefile.am | 41 +--
tests/exynos/Makefile.am | 47 +---
tests/kms/Makefile.am | 36 +--
tests/kmstest/Makefile.am | 25 +-
tests/modeprint/Makefile.am | 18 +-
tests/modetest/Makefile.am | 24 +-
tests/modetest/Makefile.sources | 6 +-
tests/nouveau/Makefile.am | 16 +-
tests/proptest/Makefile.am | 21 +-
tests/proptest/Makefile.sources | 2 +-
tests/radeon/Makefile.am | 14 +-
tests/tegra/Makefile.am | 13 +-
tests/ttmtest/Makefile.am | 1 +-
tests/ttmtest/src/Makefile.am | 8 +-
tests/util/Makefile.am | 13 +-
tests/util/Makefile.sources | 8 +-
tests/vbltest/Makefile.am | 19 +-
vc4/Makefile.am | 34 +--
vc4/Makefile.sources | 3 +-
vc4/libdrm_vc4.pc.in | 9 +-
58 files changed, 1976 deletions(-)
delete mode 100644 Makefile.am
delete mode 100644 Makefile.sources
delete mode 100644 amdgpu/Makefile.am
delete mode 100644 amdgpu/Makefile.sources
delete mode 100644 amdgpu/libdrm_amdgpu.pc.in
delete mode 100755 autogen.sh
delete mode 100644 configure.ac
delete mode 100644 etnaviv/Makefile.am
delete mode 100644 etnaviv/Makefile.sources
delete mode 100644 etnaviv/libdrm_etnaviv.pc.in
delete mode 100644 exynos/Makefile.am
delete mode 100644 exynos/libdrm_exynos.pc.in
delete mode 100644 freedreno/Makefile.am
delete mode 100644 freedreno/Makefile.sources
delete mode 100644 freedreno/libdrm_freedreno.pc.in
delete mode 100644 intel/Makefile.am
delete mode 100644 intel/Makefile.sources
delete mode 100644 intel/libdrm_intel.pc.in
delete mode 100644 libdrm.pc.in
delete mode 100644 libkms/Makefile.am
delete mode 100644 libkms/Makefile.sources
delete mode 100644 libkms/libkms.pc.in
delete mode 100644 m4/.gitignore
delete mode 100644 man/Makefile.am
delete mode 100644 nouveau/Makefile.am
delete mode 100644 nouveau/Makefile.sources
delete mode 100644 nouveau/libdrm_nouveau.pc.in
delete mode 100644 omap/Makefile.am
delete mode 100644 omap/libdrm_omap.pc.in
delete mode 100644 radeon/Makefile.am
delete mode 100644 radeon/Makefile.sources
delete mode 100644 radeon/libdrm_radeon.pc.in
delete mode 100644 tegra/Makefile.am
delete mode 100644 tegra/libdrm_tegra.pc.in
delete mode 100644 tests/Makefile.am
delete mode 100644 tests/amdgpu/Makefile.am
delete mode 100644 tests/etnaviv/Makefile.am
delete mode 100644 tests/exynos/Makefile.am
delete mode 100644 tests/kms/Makefile.am
delete mode 100644 tests/kmstest/Makefile.am
delete mode 100644 tests/modeprint/Makefile.am
delete mode 100644 tests/modetest/Makefile.am
delete mode 100644 tests/modetest/Makefile.sources
delete mode 100644 tests/nouveau/Makefile.am
delete mode 100644 tests/proptest/Makefile.am
delete mode 100644 tests/proptest/Makefile.sources
delete mode 100644 tests/radeon/Makefile.am
delete mode 100644 tests/tegra/Makefile.am
delete mode 100644 tests/ttmtest/Makefile.am
delete mode 100644 tests/ttmtest/src/Makefile.am
delete mode 100644 tests/util/Makefile.am
delete mode 100644 tests/util/Makefile.sources
delete mode 100644 tests/vbltest/Makefile.am
delete mode 100644 vc4/Makefile.am
delete mode 100644 vc4/Makefile.sources
delete mode 100644 vc4/libdrm_vc4.pc.in
diff --git a/.editorconfig b/.editorconfig
index ffc477f..089d083 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -14,10 +14,6 @@ indent_size = 4
[{Makefile.*,*.mk}]
indent_style = tab
-[*.m4]
-indent_style = space
-indent_size = 2
-
[meson.build]
indent_style = space
indent_size = 2
diff --git a/.gitignore b/.gitignore
index d51e619..b5c95d8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,67 +5,15 @@ bsd-core/*/machine
*.3
*.5
*.7
-*.flags
-*.ko
-*.ko.cmd
-*.la
-*.lo
-*.log
-*.mod.c
-*.mod.o
-*.o
-*.o.cmd
-*.sw?
-*.trs
-.depend
-.deps
-.libs
-.tmp_versions
-.*check*
-.*install*
-Makefile
-Makefile.in
-TAGS
-aclocal.m4
-autom4te.cache
-build-aux
bus_if.h
-compile
-config.guess
-config.h
-config.h.in
-config.log
-config.status
-config.sub
-configure
-configure.lineno
cscope.*
-depcomp
device_if.h
drm.kld
drm_pciids.h
export_syms
i915.kld
-install-sh
-libdrm/config.h.in
-libdrm.pc
-libdrm_intel.pc
-libdrm_nouveau.pc
-libdrm_radeon.pc
-libdrm_omap.pc
-libdrm_exynos.pc
-libdrm_freedreno.pc
-libdrm_amdgpu.pc
-libdrm_vc4.pc
-libdrm_etnaviv.pc
-libkms.pc
-libtool
-ltmain.sh
mach64.kld
-man/.man_fixup
mga.kld
-missing
-mkinstalldirs
opt_drm.h
pci_if.h
r128.kld
@@ -75,34 +23,4 @@ sis.kld
stamp-h1
tdfx.kld
via.kld
-tests/auth
-tests/amdgpu/amdgpu_test
-tests/dristat
-tests/drmdevice
-tests/drmsl
-tests/drmstat
-tests/getclient
-tests/getstats
-tests/getversion
-tests/hash
-tests/lock
-tests/openclose
-tests/random
-tests/setversion
-tests/updatedraw
-tests/modeprint/modeprint
-tests/modetest/modetest
-tests/name_from_fd
-tests/proptest/proptest
-tests/kms/kms-steal-crtc
-tests/kms/kms-universal-planes
-tests/kmstest/kmstest
-tests/vbltest/vbltest
-tests/radeon/radeon_ttm
-tests/exynos/exynos_fimg2d_event
-tests/exynos/exynos_fimg2d_perf
-tests/exynos/exynos_fimg2d_test
-tests/etnaviv/etnaviv_2d_test
-tests/etnaviv/etnaviv_cmd_stream_test
-tests/etnaviv/etnaviv_bo_cache_test
man/*.3
diff --git a/Makefile.am b/Makefile.am
deleted file mode 100644
index dfb8fcd..0000000
--- a/Makefile.am
+++ /dev/null
@@ -1,144 +0,0 @@
-# Copyright 2005 Adam Jackson.
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# on the rights to use, copy, modify, merge, publish, distribute, sub
-# license, and/or sell copies of the Software, and to permit persons to whom
-# the Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice (including the next
-# paragraph) shall be included in all copies or substantial portions of the
-# Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
-# ADAM JACKSON BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
-# IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
-# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-
-include Makefile.sources
-
-ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
-
-AM_MAKEFLAGS = -s
-AM_DISTCHECK_CONFIGURE_FLAGS = \
- --enable-udev \
- --enable-libkms \
- --enable-intel \
- --enable-radeon \
- --enable-amdgpu \
- --enable-nouveau \
- --enable-vc4 \
- --enable-vmwgfx \
- --enable-omap-experimental-api \
- --enable-exynos-experimental-api \
- --enable-freedreno \
- --enable-freedreno-kgsl\
- --enable-tegra-experimental-api \
- --enable-etnaviv-experimental-api \
- --enable-install-test-programs \
- --enable-cairo-tests \
- --enable-manpages \
- --enable-valgrind
-
-pkgconfigdir = @pkgconfigdir@
-pkgconfig_DATA = libdrm.pc
-
-if HAVE_LIBKMS
-LIBKMS_SUBDIR = libkms
-endif
-
-if HAVE_INTEL
-INTEL_SUBDIR = intel
-endif
-
-if HAVE_NOUVEAU
-NOUVEAU_SUBDIR = nouveau
-endif
-
-if HAVE_RADEON
-RADEON_SUBDIR = radeon
-endif
-
-if HAVE_AMDGPU
-AMDGPU_SUBDIR = amdgpu
-endif
-
-if HAVE_OMAP
-OMAP_SUBDIR = omap
-endif
-
-if HAVE_EXYNOS
-EXYNOS_SUBDIR = exynos
-endif
-
-if HAVE_FREEDRENO
-FREEDRENO_SUBDIR = freedreno
-endif
-
-if HAVE_TEGRA
-TEGRA_SUBDIR = tegra
-endif
-
-if HAVE_VC4
-VC4_SUBDIR = vc4
-endif
-
-if HAVE_ETNAVIV
-ETNAVIV_SUBDIR = etnaviv
-endif
-
-if BUILD_MANPAGES
-if HAVE_MANPAGES_STYLESHEET
-MAN_SUBDIR = man
-endif
-endif
-
-SUBDIRS = \
- . \
- $(LIBKMS_SUBDIR) \
- $(INTEL_SUBDIR) \
- $(NOUVEAU_SUBDIR) \
- $(RADEON_SUBDIR) \
- $(AMDGPU_SUBDIR) \
- $(OMAP_SUBDIR) \
- $(EXYNOS_SUBDIR) \
- $(FREEDRENO_SUBDIR) \
- $(TEGRA_SUBDIR) \
- $(VC4_SUBDIR) \
- $(ETNAVIV_SUBDIR) \
- tests \
- $(MAN_SUBDIR)
-
-libdrm_la_LTLIBRARIES = libdrm.la
-libdrm_ladir = $(libdir)
-libdrm_la_LDFLAGS = -version-number 2:4:0 -no-undefined
-libdrm_la_LIBADD = @CLOCK_LIB@ -lm
-
-libdrm_la_CPPFLAGS = -I$(top_srcdir)/include/drm
-AM_CFLAGS = \
- $(WARN_CFLAGS) \
- $(VALGRIND_CFLAGS)
-
-libdrm_la_SOURCES = $(LIBDRM_FILES)
-
-libdrmincludedir = ${includedir}
-libdrminclude_HEADERS = $(LIBDRM_H_FILES)
-
-klibdrmincludedir = ${includedir}/libdrm
-klibdrminclude_HEADERS = $(LIBDRM_INCLUDE_H_FILES)
-
-if HAVE_VMWGFX
-klibdrminclude_HEADERS += $(LIBDRM_INCLUDE_VMWGFX_H_FILES)
-endif
-
-EXTRA_DIST = include/drm/README
-
-copy-headers :
- cp -r $(kernel_source)/include/uapi/drm/*.h $(top_srcdir)/include/drm/
-
-commit-headers : copy-headers
- git add include/drm/*.h
- git commit -am "Copy headers from kernel $$(GIT_DIR=$(kernel_source)/.git git describe)"
diff --git a/Makefile.sources b/Makefile.sources
deleted file mode 100644
index 10aa1d0..0000000
--- a/Makefile.sources
+++ /dev/null
@@ -1,41 +0,0 @@
-LIBDRM_FILES := \
- xf86drm.c \
- xf86drmHash.c \
- xf86drmHash.h \
- xf86drmRandom.c \
- xf86drmRandom.h \
- xf86drmSL.c \
- xf86drmMode.c \
- xf86atomic.h \
- libdrm_macros.h \
- libdrm_lists.h \
- util_double_list.h \
- util_math.h
-
-LIBDRM_H_FILES := \
- libsync.h \
- xf86drm.h \
- xf86drmMode.h
-
-LIBDRM_INCLUDE_H_FILES := \
- include/drm/drm.h \
- include/drm/drm_fourcc.h \
- include/drm/drm_mode.h \
- include/drm/drm_sarea.h \
- include/drm/i915_drm.h \
- include/drm/mach64_drm.h \
- include/drm/mga_drm.h \
- include/drm/nouveau_drm.h \
- include/drm/qxl_drm.h \
- include/drm/r128_drm.h \
- include/drm/radeon_drm.h \
- include/drm/amdgpu_drm.h \
- include/drm/savage_drm.h \
- include/drm/sis_drm.h \
- include/drm/tegra_drm.h \
- include/drm/vc4_drm.h \
- include/drm/via_drm.h \
- include/drm/virtgpu_drm.h
-
-LIBDRM_INCLUDE_VMWGFX_H_FILES := \
- include/drm/vmwgfx_drm.h
diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am
deleted file mode 100644
index cf7bc1b..0000000
--- a/amdgpu/Makefile.am
+++ /dev/null
@@ -1,47 +0,0 @@
-# Copyright © 2008 Jérôme Glisse
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice (including the next
-# paragraph) shall be included in all copies or substantial portions of the
-# Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
-# IN THE SOFTWARE.
-#
-# Authors:
-# Jérôme Glisse <glisse@freedesktop.org>
-
-include Makefile.sources
-
-AM_CFLAGS = \
- $(WARN_CFLAGS) \
- -I$(top_srcdir) \
- $(PTHREADSTUBS_CFLAGS) \
- -I$(top_srcdir)/include/drm
-
-libdrm_amdgpu_la_LTLIBRARIES = libdrm_amdgpu.la
-libdrm_amdgpu_ladir = $(libdir)
-libdrm_amdgpu_la_LDFLAGS = -version-number 1:0:0 -no-undefined
-libdrm_amdgpu_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
-
-libdrm_amdgpu_la_SOURCES = $(LIBDRM_AMDGPU_FILES)
-
-libdrm_amdgpuincludedir = ${includedir}/libdrm
-libdrm_amdgpuinclude_HEADERS = $(LIBDRM_AMDGPU_H_FILES)
-
-pkgconfigdir = @pkgconfigdir@
-pkgconfig_DATA = libdrm_amdgpu.pc
-
-TESTS = amdgpu-symbol-check
-EXTRA_DIST = $(TESTS)
diff --git a/amdgpu/Makefile.sources b/amdgpu/Makefile.sources
deleted file mode 100644
index 487b9e0..0000000
--- a/amdgpu/Makefile.sources
+++ /dev/null
@@ -1,15 +0,0 @@
-LIBDRM_AMDGPU_FILES := \
- amdgpu_asic_id.h \
- amdgpu_bo.c \
- amdgpu_cs.c \
- amdgpu_device.c \
- amdgpu_gpu_info.c \
- amdgpu_internal.h \
- amdgpu_vamgr.c \
- util_hash.c \
- util_hash.h \
- util_hash_table.c \
- util_hash_table.h
-
-LIBDRM_AMDGPU_H_FILES := \
- amdgpu.h
diff --git a/amdgpu/libdrm_amdgpu.pc.in b/amdgpu/libdrm_amdgpu.pc.in
deleted file mode 100644
index f1c552a..0000000
--- a/amdgpu/libdrm_amdgpu.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: libdrm_amdgpu
-Description: Userspace interface to kernel DRM services for amdgpu
-Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -ldrm_amdgpu
-Cflags: -I${includedir} -I${includedir}/libdrm
-Requires.private: libdrm
diff --git a/autogen.sh b/autogen.sh
deleted file mode 100755
index 13d6991..0000000
--- a/autogen.sh
+++ /dev/null
@@ -1,20 +0,0 @@
-#! /bin/sh
-
-srcdir=`dirname "$0"`
-test -z "$srcdir" && srcdir=.
-
-ORIGDIR=`pwd`
-cd "$srcdir"
-
-git config --local --get format.subjectPrefix >/dev/null ||
- git config --local format.subjectPrefix "PATCH libdrm" 2>/dev/null
-
-git config --local --get sendemail.to >/dev/null ||
- git config --local sendemail.to "dri-devel@lists.freedesktop.org" 2>/dev/null
-
-autoreconf --force --verbose --install || exit 1
-cd "$ORIGDIR" || exit $?
-
-if test -z "$NOCONFIGURE"; then
- "$srcdir"/configure "$@"
-fi
diff --git a/configure.ac b/configure.ac
deleted file mode 100644
index 8e59332..0000000
--- a/configure.ac
+++ /dev/null
@@ -1,568 +0,0 @@
-# Copyright 2005 Adam Jackson.
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# on the rights to use, copy, modify, merge, publish, distribute, sub
-# license, and/or sell copies of the Software, and to permit persons to whom
-# the Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice (including the next
-# paragraph) shall be included in all copies or substantial portions of the
-# Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
-# ADAM JACKSON BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
-# IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
-# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-
-AC_PREREQ([2.63])
-AC_INIT([libdrm],
- [2.4.75],
- [https://bugs.freedesktop.org/enter_bug.cgi?product=DRI],
- [libdrm])
-
-AC_CONFIG_HEADERS([config.h])
-AC_CONFIG_SRCDIR([Makefile.am])
-AC_CONFIG_MACRO_DIR([m4])
-AC_CONFIG_AUX_DIR([build-aux])
-
-# Require xorg-macros minimum of 1.12 for XORG_WITH_XSLTPROC
-m4_ifndef([XORG_MACROS_VERSION],
- [m4_fatal([must install xorg-macros 1.12 or later before running autoconf/autogen])])
-XORG_MACROS_VERSION(1.12)
-XORG_WITH_XSLTPROC
-XORG_MANPAGE_SECTIONS
-
-AM_INIT_AUTOMAKE([1.10 foreign dist-bzip2])
-
-# Enable quiet compiles on automake 1.11.
-m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
-
-# Check for programs
-AC_PROG_CC
-AC_PROG_CC_C99
-
-if test "x$ac_cv_prog_cc_c99" = xno; then
- AC_MSG_ERROR([Building libdrm requires C99 enabled compiler])
-fi
-
-AC_USE_SYSTEM_EXTENSIONS
-AC_SYS_LARGEFILE
-AC_FUNC_ALLOCA
-
-AC_HEADER_MAJOR
-AC_CHECK_HEADERS([sys/sysctl.h sys/select.h])
-
-# Initialize libtool
-LT_PREREQ([2.2])
-LT_INIT([disable-static])
-
-
-
-AC_SUBST(PTHREADSTUBS_CFLAGS)
-AC_SUBST(PTHREADSTUBS_LIBS)
-
-pkgconfigdir=${libdir}/pkgconfig
-AC_SUBST(pkgconfigdir)
-AC_ARG_ENABLE([udev],
- [AS_HELP_STRING([--enable-udev],
- [Enable support for using udev instead of mknod (default: disabled)])],
- [UDEV=$enableval], [UDEV=no])
-
-AC_ARG_ENABLE(libkms,
- AS_HELP_STRING([--disable-libkms],
- [Disable KMS mm abstraction library (default: auto, enabled on supported platforms)]),
- [LIBKMS=$enableval], [LIBKMS=auto])
-
-AC_ARG_ENABLE(intel,
- AS_HELP_STRING([--disable-intel],
- [Enable support for intel's KMS API (default: auto, enabled on x86)]),
- [INTEL=$enableval], [INTEL=auto])
-
-AC_ARG_ENABLE(radeon,
- AS_HELP_STRING([--disable-radeon],
- [Enable support for radeon's KMS API (default: auto)]),
- [RADEON=$enableval], [RADEON=auto])
-
-AC_ARG_ENABLE(amdgpu,
- AS_HELP_STRING([--disable-amdgpu],
- [Enable support for amdgpu's KMS API (default: auto)]),
- [AMDGPU=$enableval], [AMDGPU=auto])
-
-AC_ARG_ENABLE(nouveau,
- AS_HELP_STRING([--disable-nouveau],
- [Enable support for nouveau's KMS API (default: auto)]),
- [NOUVEAU=$enableval], [NOUVEAU=auto])
-
-AC_ARG_ENABLE(vmwgfx,
- AS_HELP_STRING([--disable-vmwgfx],
- [Enable support for vmwgfx's KMS API (default: yes)]),
- [VMWGFX=$enableval], [VMWGFX=yes])
-
-AC_ARG_ENABLE(omap-experimental-api,
- AS_HELP_STRING([--enable-omap-experimental-api],
- [Enable support for OMAP's experimental API (default: disabled)]),
- [OMAP=$enableval], [OMAP=no])
-
-AC_ARG_ENABLE(exynos-experimental-api,
- AS_HELP_STRING([--enable-exynos-experimental-api],
- [Enable support for EXYNOS's experimental API (default: disabled)]),
- [EXYNOS=$enableval], [EXYNOS=no])
-
-AC_ARG_ENABLE(freedreno,
- AS_HELP_STRING([--disable-freedreno],
- [Enable support for freedreno's KMS API (default: auto, enabled on arm)]),
- [FREEDRENO=$enableval], [FREEDRENO=auto])
-
-AC_ARG_ENABLE(freedreno-kgsl,
- AS_HELP_STRING([--enable-freedreno-kgsl],
- [Enable support for freedreno's to use downstream android kernel API (default: disabled)]),
- [FREEDRENO_KGSL=$enableval], [FREEDRENO_KGSL=no])
-
-AC_ARG_ENABLE(tegra-experimental-api,
- AS_HELP_STRING([--enable-tegra-experimental-api],
- [Enable support for Tegra's experimental API (default: disabled)]),
- [TEGRA=$enableval], [TEGRA=no])
-
-AC_ARG_ENABLE(vc4,
- AS_HELP_STRING([--disable-vc4],
- [Enable support for vc4's API (default: auto, enabled on arm)]),
- [VC4=$enableval], [VC4=auto])
-
-AC_ARG_ENABLE(etnaviv-experimental-api,
- AS_HELP_STRING([--enable-etnaviv-experimental-api],
- [Enable support for etnaviv's experimental API (default: disabled)]),
- [ETNAVIV=$enableval], [ETNAVIV=no])
-
-AC_ARG_ENABLE(install-test-programs,
- AS_HELP_STRING([--enable-install-test-programs],
- [Install test programs (default: no)]),
- [INSTALL_TESTS=$enableval], [INSTALL_TESTS=no])
-
-dnl ===========================================================================
-dnl check compiler flags
-AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
- AC_MSG_CHECKING([whether $CC supports $1])
-
- libdrm_save_CFLAGS="$CFLAGS"
- CFLAGS="$CFLAGS $1"
-
- AC_COMPILE_IFELSE([AC_LANG_SOURCE([ ])], [libdrm_cc_flag=yes], [libdrm_cc_flag=no])
- CFLAGS="$libdrm_save_CFLAGS"
-
- if test "x$libdrm_cc_flag" = "xyes"; then
- ifelse([$2], , :, [$2])
- else
- ifelse([$3], , :, [$3])
- fi
- AC_MSG_RESULT([$libdrm_cc_flag])
-])
-
-dnl We use clock_gettime to check for timeouts in drmWaitVBlank
-
-AC_CHECK_FUNCS([clock_gettime], [CLOCK_LIB=],
- [AC_CHECK_LIB([rt], [clock_gettime], [CLOCK_LIB=-lrt],
- [AC_MSG_ERROR([Couldn't find clock_gettime])])])
-AC_SUBST([CLOCK_LIB])
-
-AC_CHECK_FUNCS([open_memstream], [HAVE_OPEN_MEMSTREAM=yes])
-
-dnl Use lots of warning flags with with gcc and compatible compilers
-
-dnl Note: if you change the following variable, the cache is automatically
-dnl skipped and all flags rechecked. So there's no need to do anything
-dnl else. If for any reason you need to force a recheck, just change
-dnl MAYBE_WARN in an ignorable way (like adding whitespace)
-
-MAYBE_WARN="-Wall -Wextra \
--Wsign-compare -Werror-implicit-function-declaration \
--Wpointer-arith -Wwrite-strings -Wstrict-prototypes \
--Wmissing-prototypes -Wmissing-declarations -Wnested-externs \
--Wpacked -Wswitch-enum -Wmissing-format-attribute \
--Wstrict-aliasing=2 -Winit-self \
--Wdeclaration-after-statement -Wold-style-definition \
--Wno-unused-parameter \
--Wno-attributes -Wno-long-long -Winline -Wshadow \
--Wno-missing-field-initializers"
-
-# invalidate cached value if MAYBE_WARN has changed
-if test "x$libdrm_cv_warn_maybe" != "x$MAYBE_WARN"; then
- unset libdrm_cv_warn_cflags
-fi
-AC_CACHE_CHECK([for supported warning flags], libdrm_cv_warn_cflags, [
- echo
- WARN_CFLAGS=""
-
- # Some warning options are not supported by all versions of
- # gcc, so test all desired options against the current
- # compiler.
- #
- # Note that there are some order dependencies
- # here. Specifically, an option that disables a warning will
- # have no net effect if a later option then enables that
- # warnings, (perhaps implicitly). So we put some grouped
- # options (-Wall and -Wextra) up front and the -Wno options
- # last.
-
- for W in $MAYBE_WARN; do
- LIBDRM_CC_TRY_FLAG([$W], [WARN_CFLAGS="$WARN_CFLAGS $W"])
- done
-
- libdrm_cv_warn_cflags=$WARN_CFLAGS
- libdrm_cv_warn_maybe=$MAYBE_WARN
-
- AC_MSG_CHECKING([which warning flags were supported])])
-WARN_CFLAGS="$libdrm_cv_warn_cflags"
-
-# Check for atomic intrinsics
-AC_CACHE_CHECK([for native atomic primitives], drm_cv_atomic_primitives, [
- drm_cv_atomic_primitives="none"
-
- AC_LINK_IFELSE([AC_LANG_PROGRAM([[
- int atomic_add(int *i) { return __sync_add_and_fetch (i, 1); }
- int atomic_cmpxchg(int *i, int j, int k) { return __sync_val_compare_and_swap (i, j, k); }
- ]],[[]])], [drm_cv_atomic_primitives="Intel"],[])
-
- if test "x$drm_cv_atomic_primitives" = "xnone"; then
- AC_CHECK_HEADER([atomic_ops.h], drm_cv_atomic_primitives="libatomic-ops")
- fi
-
- # atomic functions defined in <atomic.h> & libc on Solaris
- if test "x$drm_cv_atomic_primitives" = "xnone"; then
- AC_CHECK_FUNC([atomic_cas_uint], drm_cv_atomic_primitives="Solaris")
- fi
-])
-
-if test "x$drm_cv_atomic_primitives" = xIntel; then
- AC_DEFINE(HAVE_LIBDRM_ATOMIC_PRIMITIVES, 1,
- [Enable if your compiler supports the Intel __sync_* atomic primitives])
-fi
-if test "x$drm_cv_atomic_primitives" = "xlibatomic-ops"; then
- AC_DEFINE(HAVE_LIB_ATOMIC_OPS, 1, [Enable if you have libatomic-ops-dev installed])
-fi
-
-dnl Print out the approapriate message considering the value set be the
-dnl respective in $1.
-dnl $1 - value to be evaluated. Eg. $INTEL, $NOUVEAU, ...
-dnl $2 - libdrm shortname. Eg. intel, freedreno, ...
-dnl $3 - GPU name/brand. Eg. Intel, NVIDIA Tegra, ...
-dnl $4 - Configure switch. Eg. intel, omap-experimental-api, ...
-AC_DEFUN([LIBDRM_ATOMICS_NOT_FOUND_MSG], [
- case "x$1" in
- xyes) AC_MSG_ERROR([libdrm_$2 depends upon atomic operations, which were not found for your compiler/cpu. Try compiling with -march=native, or install the libatomics-op-dev package, or, failing both of those, disable support for $3 GPUs by passing --disable-$4 to ./configure]) ;;
- xauto) AC_MSG_WARN([Disabling $2. It depends on atomic operations, which were not found for your compiler/cpu. Try compiling with -march=native, or install the libatomics-op-dev package.]) ;;
- *) ;;
- esac
-])
-
-if test "x$drm_cv_atomic_primitives" = "xnone"; then
- LIBDRM_ATOMICS_NOT_FOUND_MSG($INTEL, intel, Intel, intel)
- INTEL=no
-
- LIBDRM_ATOMICS_NOT_FOUND_MSG($RADEON, radeon, Radeon, radeon)
- RADEON=no
-
- LIBDRM_ATOMICS_NOT_FOUND_MSG($AMDGPU, amdgpu, AMD, amdgpu)
- AMDGPU=no
-
- LIBDRM_ATOMICS_NOT_FOUND_MSG($NOUVEAU, nouveau, NVIDIA, nouveau)
- NOUVEAU=no
-
- LIBDRM_ATOMICS_NOT_FOUND_MSG($OMAP, omap, OMAP, omap-experimental-api)
- OMAP=no
-
- LIBDRM_ATOMICS_NOT_FOUND_MSG($FREEDRENO, freedreno, Qualcomm Adreno, freedreno)
- FREEDRENO=no
-
- LIBDRM_ATOMICS_NOT_FOUND_MSG($TEGRA, tegra, NVIDIA Tegra, tegra-experimental-api)
- TEGRA=no
-
- LIBDRM_ATOMICS_NOT_FOUND_MSG($ETNAVIV, etnaviv, Vivante, etnaviv-experimental-api)
- ETNAVIV=no
-else
- if test "x$INTEL" = xauto; then
- case $host_cpu in
- i?86|x86_64) INTEL=yes ;;
- *) INTEL=no ;;
- esac
- fi
- if test "x$RADEON" = xauto; then
- RADEON=yes
- fi
- if test "x$AMDGPU" = xauto; then
- AMDGPU=yes
- fi
- if test "x$NOUVEAU" = xauto; then
- NOUVEAU=yes
- fi
- if test "x$FREEDRENO" = xauto; then
- case $host_cpu in
- arm*|aarch64) FREEDRENO=yes ;;
- *) FREEDRENO=no ;;
- esac
- fi
- if test "x$VC4" = xauto; then
- case $host_cpu in
- arm*|aarch64) VC4=yes ;;
- *) VC4=no ;;
- esac
- fi
-fi
-
-if test "x$INTEL" != "xno"; then
- PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
-fi
-AC_SUBST(PCIACCESS_CFLAGS)
-AC_SUBST(PCIACCESS_LIBS)
-
-if test "x$UDEV" = xyes; then
- AC_DEFINE(UDEV, 1, [Have UDEV support])
-fi
-
-AC_CANONICAL_HOST
-if test "x$LIBKMS" = xauto ; then
- case $host_os in
- linux*) LIBKMS="yes" ;;
- freebsd* | kfreebsd*-gnu)
- LIBKMS="yes" ;;
- dragonfly*) LIBKMS="yes" ;;
- *) LIBKMS="no" ;;
- esac
-fi
-
-AM_CONDITIONAL(HAVE_LIBKMS, [test "x$LIBKMS" = xyes])
-
-AM_CONDITIONAL(HAVE_INTEL, [test "x$INTEL" = xyes])
-if test "x$INTEL" = xyes; then
- AC_DEFINE(HAVE_INTEL, 1, [Have intel support])
-fi
-
-AM_CONDITIONAL(HAVE_VMWGFX, [test "x$VMWGFX" = xyes])
-if test "x$VMWGFX" = xyes; then
- AC_DEFINE(HAVE_VMWGFX, 1, [Have vmwgfx kernel headers])
-fi
-
-AM_CONDITIONAL(HAVE_NOUVEAU, [test "x$NOUVEAU" = xyes])
-if test "x$NOUVEAU" = xyes; then
- AC_DEFINE(HAVE_NOUVEAU, 1, [Have nouveau (nvidia) support])
-fi
-
-AM_CONDITIONAL(HAVE_OMAP, [test "x$OMAP" = xyes])
-if test "x$OMAP" = xyes; then
- AC_DEFINE(HAVE_OMAP, 1, [Have OMAP support])
-fi
-
-AM_CONDITIONAL(HAVE_EXYNOS, [test "x$EXYNOS" = xyes])
-if test "x$EXYNOS" = xyes; then
- AC_DEFINE(HAVE_EXYNOS, 1, [Have EXYNOS support])
-fi
-
-AM_CONDITIONAL(HAVE_FREEDRENO, [test "x$FREEDRENO" = xyes])
-if test "x$FREEDRENO" = xyes; then
- AC_DEFINE(HAVE_FREEDRENO, 1, [Have freedreno support])
-fi
-
-if test "x$FREEDRENO_KGSL" = xyes; then
- if test "x$FREEDRENO" != xyes; then
- AC_MSG_ERROR([Cannot enable freedreno KGSL interface if freedreno is disabled])
- fi
-fi
-AM_CONDITIONAL(HAVE_FREEDRENO_KGSL, [test "x$FREEDRENO_KGSL" = xyes])
-if test "x$FREEDRENO_KGSL" = xyes; then
- AC_DEFINE(HAVE_FREEDRENO_KGSL, 1, [Have freedreno support for KGSL kernel interface])
-fi
-
-AM_CONDITIONAL(HAVE_RADEON, [test "x$RADEON" = xyes])
-if test "x$RADEON" = xyes; then
- AC_DEFINE(HAVE_RADEON, 1, [Have radeon support])
-fi
-
-if test "x$AMDGPU" != xno; then
- # Detect cunit library
- PKG_CHECK_MODULES([CUNIT], [cunit >= 2.1], [have_cunit=yes], [have_cunit=no])
- # If pkg-config does not find cunit, check it using AC_CHECK_LIB. We
- # do this because Debian (Ubuntu) lacks pkg-config file for cunit.
- # fixed in 2.1-2.dfsg-3: http://anonscm.debian.org/cgit/collab-maint/cunit.git/commit/?h=debian
- if test "x${have_cunit}" = "xno"; then
- AC_CHECK_LIB([cunit], [CU_initialize_registry], [have_cunit=yes], [have_cunit=no])
- if test "x${have_cunit}" = "xyes"; then
- CUNIT_LIBS="-lcunit"
- CUNIT_CFLAGS=""
- AC_SUBST([CUNIT_LIBS])
- AC_SUBST([CUNIT_CFLAGS])
- fi
- fi
-else
- have_cunit=no
-fi
-AM_CONDITIONAL(HAVE_CUNIT, [test "x$have_cunit" != "xno"])
-
-AM_CONDITIONAL(HAVE_AMDGPU, [test "x$AMDGPU" = xyes])
-if test "x$AMDGPU" = xyes; then
- AC_DEFINE(HAVE_AMDGPU, 1, [Have amdgpu support])
-
- AC_DEFINE(HAVE_CUNIT, [test "x$have_cunit" != "xno"], [Enable CUNIT Have amdgpu support])
-
- if test "x$have_cunit" = "xno"; then
- AC_MSG_WARN([Could not find cunit library. Disabling amdgpu tests])
- fi
-fi
-
-AM_CONDITIONAL(HAVE_TEGRA, [test "x$TEGRA" = xyes])
-if test "x$TEGRA" = xyes; then
- AC_DEFINE(HAVE_TEGRA, 1, [Have Tegra support])
-fi
-
-AM_CONDITIONAL(HAVE_VC4, [test "x$VC4" = xyes])
-if test "x$VC4" = xyes; then
- AC_DEFINE(HAVE_VC4, 1, [Have VC4 support])
-fi
-
-AM_CONDITIONAL(HAVE_ETNAVIV, [test "x$ETNAVIV" = xyes])
-if test "x$ETNAVIV" = xyes; then
- AC_DEFINE(HAVE_ETNAVIV, 1, [Have etnaviv support])
-fi
-
-AM_CONDITIONAL(HAVE_INSTALL_TESTS, [test "x$INSTALL_TESTS" = xyes])
-if test "x$INSTALL_TESTS" = xyes; then
- AC_DEFINE(HAVE_INSTALL_TESTS, 1, [Install test programs])
-fi
-
-AC_ARG_ENABLE([cairo-tests],
- [AS_HELP_STRING([--enable-cairo-tests],
- [Enable support for Cairo rendering in tests (default: auto)])],
- [CAIRO=$enableval], [CAIRO=auto])
-if test "x$CAIRO" != xno; then
- PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
-fi
-AC_MSG_CHECKING([whether to enable Cairo tests])
-if test "x$CAIRO" = xauto; then
- CAIRO="$HAVE_CAIRO"
-fi
-if test "x$CAIRO" = xyes; then
- if ! test "x$HAVE_CAIRO" = xyes; then
- AC_MSG_ERROR([Cairo support required but not present])
- fi
- AC_DEFINE(HAVE_CAIRO, 1, [Have Cairo support])
-fi
-AC_MSG_RESULT([$CAIRO])
-AM_CONDITIONAL(HAVE_CAIRO, [test "x$CAIRO" = xyes])
-
-# xsltproc for docbook manpages
-AC_ARG_ENABLE([manpages],
- AS_HELP_STRING([--enable-manpages], [enable manpages @<:@default=auto@:>@]),
- [MANS=$enableval], [MANS=auto])
-AM_CONDITIONAL([BUILD_MANPAGES], [test "x$XSLTPROC" != "x" -a "x$MANS" != "xno"])
-
-# check for offline man-pages stylesheet
-AC_MSG_CHECKING([for docbook manpages stylesheet])
-MANPAGES_STYLESHEET="http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"
-AC_PATH_PROGS_FEATURE_CHECK([XSLTPROC_TMP], [xsltproc],
- AS_IF([`"$ac_path_XSLTPROC_TMP" --nonet "$MANPAGES_STYLESHEET" > /dev/null 2>&1`],
- [HAVE_MANPAGES_STYLESHEET=yes]))
-if test "x$HAVE_MANPAGES_STYLESHEET" = "xyes"; then
- AC_SUBST(MANPAGES_STYLESHEET)
- AC_MSG_RESULT([yes])
-else
- AC_MSG_RESULT([no])
-fi
-AM_CONDITIONAL([HAVE_MANPAGES_STYLESHEET], [test "x$HAVE_MANPAGES_STYLESHEET" = "xyes"])
-
-AC_ARG_ENABLE(valgrind,
- [AS_HELP_STRING([--enable-valgrind],
- [Build libdrm with valgrind support (default: auto)])],
- [VALGRIND=$enableval], [VALGRIND=auto])
-if test "x$VALGRIND" != xno; then
- PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], [have_valgrind=no])
-fi
-AC_MSG_CHECKING([whether to enable Valgrind support])
-if test "x$VALGRIND" = xauto; then
- VALGRIND="$have_valgrind"
-fi
-
-if test "x$VALGRIND" = "xyes"; then
- if ! test "x$have_valgrind" = xyes; then
- AC_MSG_ERROR([Valgrind support required but not present])
- fi
- AC_DEFINE([HAVE_VALGRIND], 1, [Use valgrind intrinsics to suppress false warnings])
-fi
-
-AC_MSG_RESULT([$VALGRIND])
-
-AC_ARG_WITH([kernel-source],
- [AS_HELP_STRING([--with-kernel-source],
- [specify path to linux kernel source])],
- [kernel_source="$with_kernel_source"])
-AC_SUBST(kernel_source)
-
-AC_MSG_CHECKING([whether $CC supports __attribute__(("hidden"))])
-AC_LINK_IFELSE([AC_LANG_PROGRAM([
- int foo_hidden( void ) __attribute__((visibility("hidden")));
-])], HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes]), AC_MSG_RESULT([no]));
-
-if test "x$HAVE_ATTRIBUTE_VISIBILITY" = xyes; then
- AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler supports __attribute__(("hidden"))])
-fi
-
-AC_SUBST(WARN_CFLAGS)
-AC_CONFIG_FILES([
- Makefile
- libkms/Makefile
- libkms/libkms.pc
- intel/Makefile
- intel/libdrm_intel.pc
- radeon/Makefile
- radeon/libdrm_radeon.pc
- amdgpu/Makefile
- amdgpu/libdrm_amdgpu.pc
- nouveau/Makefile
- nouveau/libdrm_nouveau.pc
- omap/Makefile
- omap/libdrm_omap.pc
- exynos/Makefile
- exynos/libdrm_exynos.pc
- freedreno/Makefile
- freedreno/libdrm_freedreno.pc
- tegra/Makefile
- tegra/libdrm_tegra.pc
- vc4/Makefile
- vc4/libdrm_vc4.pc
- etnaviv/Makefile
- etnaviv/libdrm_etnaviv.pc
- tests/Makefile
- tests/modeprint/Makefile
- tests/modetest/Makefile
- tests/kms/Makefile
- tests/kmstest/Makefile
- tests/proptest/Makefile
- tests/radeon/Makefile
- tests/amdgpu/Makefile
- tests/vbltest/Makefile
- tests/exynos/Makefile
- tests/tegra/Makefile
- tests/nouveau/Makefile
- tests/etnaviv/Makefile
- tests/util/Makefile
- man/Makefile
- libdrm.pc])
-AC_OUTPUT
-
-echo ""
-echo "$PACKAGE_STRING will be compiled with:"
-echo ""
-echo " libkms $LIBKMS"
-echo " Intel API $INTEL"
-echo " vmwgfx API $VMWGFX"
-echo " Radeon API $RADEON"
-echo " AMDGPU API $AMDGPU"
-echo " Nouveau API $NOUVEAU"
-echo " OMAP API $OMAP"
-echo " EXYNOS API $EXYNOS"
-echo " Freedreno API $FREEDRENO (kgsl: $FREEDRENO_KGSL)"
-echo " Tegra API $TEGRA"
-echo " VC4 API $VC4"
-echo " Etnaviv API $ETNAVIV"
-echo ""
diff --git a/etnaviv/Makefile.am b/etnaviv/Makefile.am
deleted file mode 100644
index be96ba8..0000000
--- a/etnaviv/Makefile.am
+++ /dev/null
@@ -1,26 +0,0 @@
-include Makefile.sources
-
-AM_CFLAGS = \
- $(WARN_CFLAGS) \
- -I$(top_srcdir) \
- $(PTHREADSTUBS_CFLAGS) \
- -I$(top_srcdir)/include/drm
-
-libdrm_etnaviv_ladir = $(libdir)
-libdrm_etnaviv_la_LTLIBRARIES = libdrm_etnaviv.la
-libdrm_etnaviv_la_LDFLAGS = -version-number 1:0:0 -no-undefined
-libdrm_etnaviv_la_LIBADD = \
- ../libdrm.la \
- @PTHREADSTUBS_LIBS@ \
- @CLOCK_LIB@
-
-libdrm_etnaviv_la_SOURCES = $(LIBDRM_ETNAVIV_FILES)
-
-libdrm_etnavivincludedir = ${includedir}/libdrm
-libdrm_etnavivinclude_HEADERS = $(LIBDRM_ETNAVIV_H_FILES)
-
-pkgconfigdir = @pkgconfigdir@
-pkgconfig_DATA = libdrm_etnaviv.pc
-
-TESTS = etnaviv-symbol-check
-EXTRA_DIST = $(TESTS)
diff --git a/etnaviv/Makefile.sources b/etnaviv/Makefile.sources
deleted file mode 100644
index 5258056..0000000
--- a/etnaviv/Makefile.sources
+++ /dev/null
@@ -1,12 +0,0 @@
-LIBDRM_ETNAVIV_FILES := \
- etnaviv_device.c \
- etnaviv_gpu.c \
- etnaviv_bo.c \
- etnaviv_bo_cache.c \
- etnaviv_pipe.c \
- etnaviv_cmd_stream.c \
- etnaviv_drm.h \
- etnaviv_priv.h
-
-LIBDRM_ETNAVIV_H_FILES := \
- etnaviv_drmif.h
diff --git a/etnaviv/libdrm_etnaviv.pc.in b/etnaviv/libdrm_etnaviv.pc.in
deleted file mode 100644
index 13fed01..0000000
--- a/etnaviv/libdrm_etnaviv.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: libdrm_etnaviv
-Description: Userspace interface to etnaviv kernel DRM services
-Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -ldrm_etnaviv
-Cflags: -I${includedir} -I${includedir}/libdrm
-Requires.private: libdrm
diff --git a/exynos/Makefile.am b/exynos/Makefile.am
deleted file mode 100644
index f99f898..0000000
--- a/exynos/Makefile.am
+++ /dev/null
@@ -1,27 +0,0 @@
-AM_CFLAGS = \
- $(WARN_CFLAGS) \
- -I$(top_srcdir) \
- $(PTHREADSTUBS_CFLAGS) \
- -I$(top_srcdir)/include/drm
-
-libdrm_exynos_la_LTLIBRARIES = libdrm_exynos.la
-libdrm_exynos_ladir = $(libdir)
-libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
-libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
-
-libdrm_exynos_la_SOURCES = \
- exynos_drm.c \
- exynos_fimg2d.c \
- fimg2d_reg.h
-
-libdrm_exynoscommonincludedir = ${includedir}/exynos
-libdrm_exynoscommoninclude_HEADERS = exynos_drm.h exynos_fimg2d.h
-
-libdrm_exynosincludedir = ${includedir}/libdrm
-libdrm_exynosinclude_HEADERS = exynos_drmif.h
-
-pkgconfigdir = @pkgconfigdir@
-pkgconfig_DATA = libdrm_exynos.pc
-
-TESTS = exynos-symbol-check
-EXTRA_DIST = $(TESTS)
diff --git a/exynos/libdrm_exynos.pc.in b/exynos/libdrm_exynos.pc.in
deleted file mode 100644
index ff1c432..0000000
--- a/exynos/libdrm_exynos.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: libdrm_exynos
-Description: Userspace interface to exynos kernel DRM services
-Version: 0.7
-Libs: -L${libdir} -ldrm_exynos
-Cflags: -I${includedir} -I${includedir}/libdrm -I${includedir}/exynos
-Requires.private: libdrm
diff --git a/freedreno/Makefile.am b/freedreno/Makefile.am
deleted file mode 100644
index 0771d14..0000000
--- a/freedreno/Makefile.am
+++ /dev/null
@@ -1,30 +0,0 @@
-AUTOMAKE_OPTIONS=subdir-objects
-include Makefile.sources
-
-AM_CFLAGS = \
- $(WARN_CFLAGS) \
- -I$(top_srcdir) \
- $(PTHREADSTUBS_CFLAGS) \
- -I$(top_srcdir)/include/drm
-
-libdrm_freedreno_la_LTLIBRARIES = libdrm_freedreno.la
-libdrm_freedreno_ladir = $(libdir)
-libdrm_freedreno_la_LDFLAGS = -version-number 1:0:0 -no-undefined
-libdrm_freedreno_la_LIBADD = \
- ../libdrm.la \
- @PTHREADSTUBS_LIBS@ \
- @CLOCK_LIB@
-
-libdrm_freedreno_la_SOURCES = $(LIBDRM_FREEDRENO_FILES)
-if HAVE_FREEDRENO_KGSL
-libdrm_freedreno_la_SOURCES += $(LIBDRM_FREEDRENO_KGSL_FILES)
-endif
-
-libdrm_freedrenocommonincludedir = ${includedir}/freedreno
-libdrm_freedrenocommoninclude_HEADERS = $(LIBDRM_FREEDRENO_H_FILES)
-
-pkgconfigdir = @pkgconfigdir@
-pkgconfig_DATA = libdrm_freedreno.pc
-
-TESTS = freedreno-symbol-check
-EXTRA_DIST = $(TESTS)
diff --git a/freedreno/Makefile.sources b/freedreno/Makefile.sources
deleted file mode 100644
index 68a679b..0000000
--- a/freedreno/Makefile.sources
+++ /dev/null
@@ -1,26 +0,0 @@
-LIBDRM_FREEDRENO_FILES := \
- freedreno_device.c \
- freedreno_pipe.c \
- freedreno_priv.h \
- freedreno_ringbuffer.c \
- freedreno_bo.c \
- freedreno_bo_cache.c \
- msm/msm_bo.c \
- msm/msm_device.c \
- msm/msm_drm.h \
- msm/msm_pipe.c \
- msm/msm_priv.h \
- msm/msm_ringbuffer.c
-
-LIBDRM_FREEDRENO_KGSL_FILES := \
- kgsl/kgsl_bo.c \
- kgsl/kgsl_device.c \
- kgsl/kgsl_drm.h \
- kgsl/kgsl_pipe.c \
- kgsl/kgsl_priv.h \
- kgsl/kgsl_ringbuffer.c \
- kgsl/msm_kgsl.h
-
-LIBDRM_FREEDRENO_H_FILES := \
- freedreno_drmif.h \
- freedreno_ringbuffer.h
diff --git a/freedreno/libdrm_freedreno.pc.in b/freedreno/libdrm_freedreno.pc.in
deleted file mode 100644
index b736b65..0000000
--- a/freedreno/libdrm_freedreno.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: libdrm_freedreno
-Description: Userspace interface to freedreno kernel DRM services
-Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -ldrm_freedreno
-Cflags: -I${includedir} -I${includedir}/libdrm -I${includedir}/freedreno
-Requires.private: libdrm
diff --git a/intel/Makefile.am b/intel/Makefile.am
deleted file mode 100644
index c52e8c0..0000000
--- a/intel/Makefile.am
+++ /dev/null
@@ -1,73 +0,0 @@
-# Copyright © 2008 Intel Corporation
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice (including the next
-# paragraph) shall be included in all copies or substantial portions of the
-# Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
-# IN THE SOFTWARE.
-#
-# Authors:
-# Eric Anholt <eric@anholt.net>
-
-include Makefile.sources
-
-AM_CFLAGS = \
- $(WARN_CFLAGS) \
- -I$(top_srcdir) \
- $(PTHREADSTUBS_CFLAGS) \
- $(PCIACCESS_CFLAGS) \
- $(VALGRIND_CFLAGS) \
- -I$(top_srcdir)/include/drm
-
-libdrm_intel_la_LTLIBRARIES = libdrm_intel.la
-libdrm_intel_ladir = $(libdir)
-libdrm_intel_la_LDFLAGS = -version-number 1:0:0 -no-undefined
-libdrm_intel_la_LIBADD = ../libdrm.la \
- @PTHREADSTUBS_LIBS@ \
- @PCIACCESS_LIBS@ \
- @CLOCK_LIB@
-
-libdrm_intel_la_SOURCES = $(LIBDRM_INTEL_FILES)
-
-libdrm_intelincludedir = ${includedir}/libdrm
-libdrm_intelinclude_HEADERS = $(LIBDRM_INTEL_H_FILES)
-
-# This may be interesting even outside of "make check", due to the -dump option.
-noinst_PROGRAMS = test_decode
-
-BATCHES = \
- tests/gen4-3d.batch \
- tests/gm45-3d.batch \
- tests/gen5-3d.batch \
- tests/gen6-3d.batch \
- tests/gen7-2d-copy.batch \
- tests/gen7-3d.batch
-
-TESTS = \
- $(BATCHES:.batch=.batch.sh) \
- intel-symbol-check
-
-EXTRA_DIST = \
- $(BATCHES) \
- $(BATCHES:.batch=.batch.sh) \
- $(BATCHES:.batch=.batch-ref.txt) \
- $(BATCHES:.batch=.batch-ref.txt) \
- tests/test-batch.sh \
- $(TESTS)
-
-test_decode_LDADD = libdrm_intel.la ../libdrm.la
-
-pkgconfig_DATA = libdrm_intel.pc
diff --git a/intel/Makefile.sources b/intel/Makefile.sources
deleted file mode 100644
index 6947ab7..0000000
--- a/intel/Makefile.sources
+++ /dev/null
@@ -1,15 +0,0 @@
-LIBDRM_INTEL_FILES := \
- intel_bufmgr.c \
- intel_bufmgr_priv.h \
- intel_bufmgr_fake.c \
- intel_bufmgr_gem.c \
- intel_decode.c \
- intel_chipset.h \
- mm.c \
- mm.h \
- uthash.h
-
-LIBDRM_INTEL_H_FILES := \
- intel_bufmgr.h \
- intel_aub.h \
- intel_debug.h
diff --git a/intel/libdrm_intel.pc.in b/intel/libdrm_intel.pc.in
deleted file mode 100644
index 670e4fe..0000000
--- a/intel/libdrm_intel.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: libdrm_intel
-Description: Userspace interface to intel kernel DRM services
-Version: @PACKAGE_VERSION@
-Requires: libdrm
-Libs: -L${libdir} -ldrm_intel
-Cflags: -I${includedir} -I${includedir}/libdrm
diff --git a/libdrm.pc.in b/libdrm.pc.in
deleted file mode 100644
index b46e2a6..0000000
--- a/libdrm.pc.in
+++ /dev/null
@@ -1,10 +0,0 @@
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: libdrm
-Description: Userspace interface to kernel DRM services
-Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -ldrm
-Cflags: -I${includedir} -I${includedir}/libdrm
diff --git a/libkms/Makefile.am b/libkms/Makefile.am
deleted file mode 100644
index 461fc35..0000000
--- a/libkms/Makefile.am
+++ /dev/null
@@ -1,43 +0,0 @@
-include Makefile.sources
-
-AM_CFLAGS = \
- $(WARN_CFLAGS) \
- -I$(top_srcdir)/include/drm \
- -I$(top_srcdir)
-
-libkms_la_LTLIBRARIES = libkms.la
-libkms_ladir = $(libdir)
-libkms_la_LDFLAGS = -version-number 1:0:0 -no-undefined
-libkms_la_LIBADD = ../libdrm.la
-
-libkms_la_SOURCES = $(LIBKMS_FILES)
-
-if HAVE_VMWGFX
-libkms_la_SOURCES += $(LIBKMS_VMWGFX_FILES)
-endif
-
-if HAVE_INTEL
-libkms_la_SOURCES += $(LIBKMS_INTEL_FILES)
-endif
-
-if HAVE_NOUVEAU
-libkms_la_SOURCES += $(LIBKMS_NOUVEAU_FILES)
-endif
-
-if HAVE_RADEON
-libkms_la_SOURCES += $(LIBKMS_RADEON_FILES)
-endif
-
-if HAVE_EXYNOS
-libkms_la_SOURCES += $(LIBKMS_EXYNOS_FILES)
-AM_CFLAGS += -I$(top_srcdir)/exynos
-endif
-
-libkmsincludedir = ${includedir}/libkms
-libkmsinclude_HEADERS = $(LIBKMS_H_FILES)
-
-pkgconfigdir = @pkgconfigdir@
-pkgconfig_DATA = libkms.pc
-
-TESTS = kms-symbol-check
-EXTRA_DIST = $(TESTS)
diff --git a/libkms/Makefile.sources b/libkms/Makefile.sources
deleted file mode 100644
index 3191f51..0000000
--- a/libkms/Makefile.sources
+++ /dev/null
@@ -1,23 +0,0 @@
-LIBKMS_FILES := \
- internal.h \
- linux.c \
- dumb.c \
- api.c
-
-LIBKMS_VMWGFX_FILES := \
- vmwgfx.c
-
-LIBKMS_INTEL_FILES := \
- intel.c
-
-LIBKMS_NOUVEAU_FILES := \
- nouveau.c
-
-LIBKMS_RADEON_FILES := \
- radeon.c
-
-LIBKMS_EXYNOS_FILES := \
- exynos.c
-
-LIBKMS_H_FILES := \
- libkms.h
diff --git a/libkms/libkms.pc.in b/libkms/libkms.pc.in
deleted file mode 100644
index 1421b3e..0000000
--- a/libkms/libkms.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: libkms
-Description: Library that abstract aways the different mm interface for kernel drivers
-Version: 1.0.0
-Libs: -L${libdir} -lkms
-Cflags: -I${includedir}/libkms
-Requires.private: libdrm
diff --git a/m4/.gitignore b/m4/.gitignore
deleted file mode 100644
index 464ba5c..0000000
--- a/m4/.gitignore
+++ /dev/null
@@ -1,5 +0,0 @@
-libtool.m4
-lt~obsolete.m4
-ltoptions.m4
-ltsugar.m4
-ltversion.m4
diff --git a/man/Makefile.am b/man/Makefile.am
deleted file mode 100644
index 00eb423..0000000
--- a/man/Makefile.am
+++ /dev/null
@@ -1,62 +0,0 @@
-#
-# This generates man-pages out of the Docbook XML files. Simply add your files
-# to the relevant *man_PRE array. If aliases are created, please add them to the
-# *man_aliases_PRE array so they get installed correctly.
-#
-
-libman_PRE = \
- drmAvailable.xml \
- drmHandleEvent.xml \
- drmModeGetResources.xml
-
-miscman_PRE = \
- drm.xml \
- drm-kms.xml \
- drm-memory.xml
-
-miscman_aliases_PRE = \
- drm-mm.xml \
- drm-gem.xml \
- drm-ttm.xml
-
-libmandir = $(LIB_MAN_DIR)
-miscmandir = $(MISC_MAN_DIR)
-miscman_aliasesdir = $(MISC_MAN_DIR)
-
-libman_DATA = $(libman_PRE:.xml=.$(LIB_MAN_SUFFIX))
-miscman_DATA = $(miscman_PRE:.xml=.$(MISC_MAN_SUFFIX))
-miscman_aliases_DATA = $(miscman_aliases_PRE:.xml=.$(MISC_MAN_SUFFIX))
-
-XML_FILES = \
- $(libman_PRE) \
- $(miscman_PRE)
-
-MAN_FILES = \
- $(libman_DATA) \
- $(miscman_DATA) \
- $(miscman_aliases_DATA)
-
-EXTRA_DIST = $(XML_FILES)
-CLEANFILES = $(MAN_FILES)
-
-XSLTPROC_FLAGS = \
- --stringparam man.authors.section.enabled 0 \
- --stringparam man.copyright.section.enabled 0 \
- --stringparam funcsynopsis.style ansi \
- --stringparam man.output.quietly 1 \
- --nonet \
- $(MANPAGES_STYLESHEET)
-
-XSLTPROC_PROCESS_MAN = \
- $(AM_V_GEN)$(XSLTPROC) -o "$@" $(XSLTPROC_FLAGS) "$<"
-
-$(miscman_aliases_DATA): $(miscman_DATA)
- $(AM_V_GEN)if test -n "$@" ; then $(SED) -i -e 's/^\.so \([a-z_]\+\)\.\([0-9]\)$$/\.so man\2\/\1\.\2/' "$@" ; fi
-
-SUFFIXES = .$(LIB_MAN_SUFFIX) .$(MISC_MAN_SUFFIX) .xml
-
-.xml.$(LIB_MAN_SUFFIX):
- $(XSLTPROC_PROCESS_MAN)
-
-.xml.$(MISC_MAN_SUFFIX):
- $(XSLTPROC_PROCESS_MAN)
diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am
deleted file mode 100644
index 344a844..0000000
--- a/nouveau/Makefile.am
+++ /dev/null
@@ -1,33 +0,0 @@
-include Makefile.sources
-
-AM_CFLAGS = \
- $(WARN_CFLAGS) \
- -I$(top_srcdir) \
- $(PTHREADSTUBS_CFLAGS) \
- -I$(top_srcdir)/include/drm \
- -DDEBUG
-
-libdrm_nouveau_la_LTLIBRARIES = libdrm_nouveau.la
-libdrm_nouveau_ladir = $(libdir)
-libdrm_nouveau_la_LDFLAGS = -version-number 2:0:0 -no-undefined
-libdrm_nouveau_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
-
-libdrm_nouveau_la_SOURCES = $(LIBDRM_NOUVEAU_FILES)
-
-libdrm_nouveauincludedir = ${includedir}/libdrm/nouveau
-libdrm_nouveauinclude_HEADERS = $(LIBDRM_NOUVEAU_H_FILES)
-
-libdrm_nouveaunvifincludedir = ${includedir}/libdrm/nouveau/nvif
-libdrm_nouveaunvifinclude_HEADERS = nvif/class.h \
- nvif/cl0080.h \
- nvif/cl9097.h \
- nvif/if0002.h \
- nvif/if0003.h \
- nvif/ioctl.h \
- nvif/unpack.h
-
-pkgconfigdir = @pkgconfigdir@
-pkgconfig_DATA = libdrm_nouveau.pc
-
-TESTS = nouveau-symbol-check
-EXTRA_DIST = $(TESTS)
diff --git a/nouveau/Makefile.sources b/nouveau/Makefile.sources
deleted file mode 100644
index 89f2a2b..0000000
--- a/nouveau/Makefile.sources
+++ /dev/null
@@ -1,9 +0,0 @@
-LIBDRM_NOUVEAU_FILES := \
- nouveau.c \
- pushbuf.c \
- bufctx.c \
- abi16.c \
- private.h
-
-LIBDRM_NOUVEAU_H_FILES := \
- nouveau.h
diff --git a/nouveau/libdrm_nouveau.pc.in b/nouveau/libdrm_nouveau.pc.in
deleted file mode 100644
index 7d0622e..0000000
--- a/nouveau/libdrm_nouveau.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: libdrm_nouveau
-Description: Userspace interface to nouveau kernel DRM services
-Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -ldrm_nouveau
-Cflags: -I${includedir} -I${includedir}/libdrm -I${includedir}/libdrm/nouveau
-Requires.private: libdrm
diff --git a/omap/Makefile.am b/omap/Makefile.am
deleted file mode 100644
index 599bb9d..0000000
--- a/omap/Makefile.am
+++ /dev/null
@@ -1,24 +0,0 @@
-AM_CFLAGS = \
- $(WARN_CFLAGS) \
- -I$(top_srcdir) \
- $(PTHREADSTUBS_CFLAGS) \
- -I$(top_srcdir)/include/drm
-
-libdrm_omap_la_LTLIBRARIES = libdrm_omap.la
-libdrm_omap_ladir = $(libdir)
-libdrm_omap_la_LDFLAGS = -version-number 1:0:0 -no-undefined
-libdrm_omap_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
-
-libdrm_omap_la_SOURCES = omap_drm.c
-
-libdrm_omapcommonincludedir = ${includedir}/omap
-libdrm_omapcommoninclude_HEADERS = omap_drm.h
-
-libdrm_omapincludedir = ${includedir}/libdrm
-libdrm_omapinclude_HEADERS = omap_drmif.h
-
-pkgconfigdir = @pkgconfigdir@
-pkgconfig_DATA = libdrm_omap.pc
-
-TESTS = omap-symbol-check
-EXTRA_DIST = $(TESTS)
diff --git a/omap/libdrm_omap.pc.in b/omap/libdrm_omap.pc.in
deleted file mode 100644
index 024533b..0000000
--- a/omap/libdrm_omap.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: libdrm_omap
-Description: Userspace interface to omap kernel DRM services
-Version: 0.6
-Libs: -L${libdir} -ldrm_omap
-Cflags: -I${includedir} -I${includedir}/libdrm -I${includedir}/omap
-Requires.private: libdrm
diff --git a/radeon/Makefile.am b/radeon/Makefile.am
deleted file mode 100644
index e241531..0000000
--- a/radeon/Makefile.am
+++ /dev/null
@@ -1,47 +0,0 @@
-# Copyright © 2008 Jérôme Glisse
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice (including the next
-# paragraph) shall be included in all copies or substantial portions of the
-# Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
-# IN THE SOFTWARE.
-#
-# Authors:
-# Jérôme Glisse <glisse@freedesktop.org>
-
-include Makefile.sources
-
-AM_CFLAGS = \
- $(WARN_CFLAGS) \
- -I$(top_srcdir) \
- $(PTHREADSTUBS_CFLAGS) \
- -I$(top_srcdir)/include/drm
-
-libdrm_radeon_la_LTLIBRARIES = libdrm_radeon.la
-libdrm_radeon_ladir = $(libdir)
-libdrm_radeon_la_LDFLAGS = -version-number 1:0:1 -no-undefined
-libdrm_radeon_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
-
-libdrm_radeon_la_SOURCES = $(LIBDRM_RADEON_FILES)
-
-libdrm_radeonincludedir = ${includedir}/libdrm
-libdrm_radeoninclude_HEADERS = $(LIBDRM_RADEON_H_FILES)
-
-pkgconfigdir = @pkgconfigdir@
-pkgconfig_DATA = libdrm_radeon.pc
-
-TESTS = radeon-symbol-check
-EXTRA_DIST = $(LIBDRM_RADEON_BOF_FILES) $(TESTS)
diff --git a/radeon/Makefile.sources b/radeon/Makefile.sources
deleted file mode 100644
index 1cf482a..0000000
--- a/radeon/Makefile.sources
+++ /dev/null
@@ -1,21 +0,0 @@
-LIBDRM_RADEON_FILES := \
- radeon_bo_gem.c \
- radeon_cs_gem.c \
- radeon_cs_space.c \
- radeon_bo.c \
- radeon_cs.c \
- radeon_surface.c
-
-LIBDRM_RADEON_H_FILES := \
- radeon_bo.h \
- radeon_cs.h \
- radeon_surface.h \
- radeon_bo_gem.h \
- radeon_cs_gem.h \
- radeon_bo_int.h \
- radeon_cs_int.h \
- r600_pci_ids.h
-
-LIBDRM_RADEON_BOF_FILES := \
- bof.c \
- bof.h
diff --git a/radeon/libdrm_radeon.pc.in b/radeon/libdrm_radeon.pc.in
deleted file mode 100644
index 432993a..0000000
--- a/radeon/libdrm_radeon.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: libdrm_radeon
-Description: Userspace interface to kernel DRM services for radeon
-Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -ldrm_radeon
-Cflags: -I${includedir} -I${includedir}/libdrm
-Requires.private: libdrm
diff --git a/tegra/Makefile.am b/tegra/Makefile.am
deleted file mode 100644
index fb40be5..0000000
--- a/tegra/Makefile.am
+++ /dev/null
@@ -1,25 +0,0 @@
-AM_CPPFLAGS = \
- -I$(top_srcdir) \
- -I$(top_srcdir)/include/drm
-
-AM_CFLAGS = \
- @PTHREADSTUBS_CFLAGS@ \
- $(WARN_CFLAGS)
-
-libdrm_tegra_ladir = $(libdir)
-libdrm_tegra_la_LTLIBRARIES = libdrm_tegra.la
-libdrm_tegra_la_LDFLAGS = -version-number 0:0:0 -no-undefined
-libdrm_tegra_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
-
-libdrm_tegra_la_SOURCES = \
- private.h \
- tegra.c
-
-libdrm_tegraincludedir = ${includedir}/libdrm
-libdrm_tegrainclude_HEADERS = tegra.h
-
-pkgconfigdir = @pkgconfigdir@
-pkgconfig_DATA = libdrm_tegra.pc
-
-TESTS = tegra-symbol-check
-EXTRA_DIST = $(TESTS)
diff --git a/tegra/libdrm_tegra.pc.in b/tegra/libdrm_tegra.pc.in
deleted file mode 100644
index 2e06f49..0000000
--- a/tegra/libdrm_tegra.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: libdrm_tegra
-Description: Userspace interface to Tegra kernel DRM services
-Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -ldrm_tegra
-Cflags: -I${includedir} -I${includedir}/libdrm
-Requires.private: libdrm
diff --git a/tests/Makefile.am b/tests/Makefile.am
deleted file mode 100644
index 0355a92..0000000
--- a/tests/Makefile.am
+++ /dev/null
@@ -1,47 +0,0 @@
-SUBDIRS = util kms modeprint proptest modetest vbltest
-
-if HAVE_LIBKMS
-SUBDIRS += kmstest
-endif
-
-if HAVE_RADEON
-SUBDIRS += radeon
-endif
-
-if HAVE_AMDGPU
-if HAVE_CUNIT
-SUBDIRS += amdgpu
-endif
-endif
-
-if HAVE_EXYNOS
-SUBDIRS += exynos
-endif
-
-if HAVE_TEGRA
-SUBDIRS += tegra
-endif
-
-if HAVE_ETNAVIV
-SUBDIRS += etnaviv
-endif
-
-if HAVE_NOUVEAU
-SUBDIRS += nouveau
-endif
-
-AM_CFLAGS = \
- $(WARN_CFLAGS)\
- -I $(top_srcdir)/include/drm \
- -I $(top_srcdir)
-
-LDADD = $(top_builddir)/libdrm.la
-
-TESTS = \
- drmsl \
- hash \
- random
-
-check_PROGRAMS = \
- $(TESTS) \
- drmdevice
diff --git a/tests/amdgpu/Makefile.am b/tests/amdgpu/Makefile.am
deleted file mode 100644
index c1c3a32..0000000
--- a/tests/amdgpu/Makefile.am
+++ /dev/null
@@ -1,29 +0,0 @@
-AM_CFLAGS = \
- -I $(top_srcdir)/include/drm \
- -I $(top_srcdir)/amdgpu \
- -I $(top_srcdir)
-
-LDADD = $(top_builddir)/libdrm.la \
- $(top_builddir)/amdgpu/libdrm_amdgpu.la \
- $(CUNIT_LIBS)
-
-if HAVE_INSTALL_TESTS
-bin_PROGRAMS = \
- amdgpu_test
-else
-noinst_PROGRAMS = \
- amdgpu_test
-endif
-
-amdgpu_test_CPPFLAGS = $(CUNIT_CFLAGS)
-
-amdgpu_test_SOURCES = \
- amdgpu_test.c \
- amdgpu_test.h \
- basic_tests.c \
- bo_tests.c \
- cs_tests.c \
- uvd_messages.h \
- vce_tests.c \
- vce_ib.h \
- frame.h
diff --git a/tests/etnaviv/Makefile.am b/tests/etnaviv/Makefile.am
deleted file mode 100644
index 0631864..0000000
--- a/tests/etnaviv/Makefile.am
+++ /dev/null
@@ -1,41 +0,0 @@
-AM_CFLAGS = \
- -I $(top_srcdir)/include/drm \
- -I $(top_srcdir)/etnaviv \
- -I $(top_srcdir)
-
-if HAVE_INSTALL_TESTS
-bin_PROGRAMS = \
- etnaviv_2d_test \
- etnaviv_cmd_stream_test \
- etnaviv_bo_cache_test
-else
-noinst_PROGRAMS = \
- etnaviv_2d_test \
- etnaviv_cmd_stream_test \
- etnaviv_bo_cache_test
-endif
-
-etnaviv_2d_test_LDADD = \
- $(top_builddir)/libdrm.la \
- $(top_builddir)/etnaviv/libdrm_etnaviv.la
-
-etnaviv_2d_test_SOURCES = \
- cmdstream.xml.h \
- etnaviv_2d_test.c \
- state.xml.h \
- state_2d.xml.h \
- write_bmp.c \
- write_bmp.h
-
-etnaviv_cmd_stream_test_LDADD = \
- $(top_builddir)/etnaviv/libdrm_etnaviv.la
-
-etnaviv_cmd_stream_test_SOURCES = \
- etnaviv_cmd_stream_test.c
-
-etnaviv_bo_cache_test_LDADD = \
- $(top_builddir)/libdrm.la \
- $(top_builddir)/etnaviv/libdrm_etnaviv.la
-
-etnaviv_bo_cache_test_SOURCES = \
- etnaviv_bo_cache_test.c
diff --git a/tests/exynos/Makefile.am b/tests/exynos/Makefile.am
deleted file mode 100644
index b636172..0000000
--- a/tests/exynos/Makefile.am
+++ /dev/null
@@ -1,47 +0,0 @@
-AM_CFLAGS = \
- -pthread \
- $(WARN_CFLAGS)\
- -I $(top_srcdir)/include/drm \
- -I $(top_srcdir)/libkms/ \
- -I $(top_srcdir)/exynos \
- -I $(top_srcdir)
-
-bin_PROGRAMS =
-noinst_PROGRAMS =
-
-if HAVE_LIBKMS
-if HAVE_INSTALL_TESTS
-bin_PROGRAMS += \
- exynos_fimg2d_test
-else
-noinst_PROGRAMS += \
- exynos_fimg2d_test
-endif
-endif
-
-if HAVE_INSTALL_TESTS
-bin_PROGRAMS += \
- exynos_fimg2d_perf \
- exynos_fimg2d_event
-else
-noinst_PROGRAMS += \
- exynos_fimg2d_perf \
- exynos_fimg2d_event
-endif
-
-exynos_fimg2d_perf_LDADD = \
- $(top_builddir)/libdrm.la \
- $(top_builddir)/exynos/libdrm_exynos.la
-
-exynos_fimg2d_event_LDADD = \
- $(top_builddir)/libdrm.la \
- $(top_builddir)/exynos/libdrm_exynos.la
-
-exynos_fimg2d_test_LDADD = \
- $(top_builddir)/libdrm.la \
- $(top_builddir)/libkms/libkms.la \
- $(top_builddir)/exynos/libdrm_exynos.la
-
-exynos_fimg2d_test_SOURCES = \
- exynos_fimg2d_test.c
-
diff --git a/tests/kms/Makefile.am b/tests/kms/Makefile.am
deleted file mode 100644
index 6645af7..0000000
--- a/tests/kms/Makefile.am
+++ /dev/null
@@ -1,36 +0,0 @@
-AM_CPPFLAGS = \
- -I$(top_srcdir)/include/drm \
- -I$(top_srcdir)/tests \
- -I$(top_srcdir)
-
-AM_CFLAGS = \
- $(WARN_CFLAGS)
-
-noinst_LTLIBRARIES = libkms-test.la
-
-libkms_test_la_SOURCES = \
- libkms-test.h \
- libkms-test-crtc.c \
- libkms-test-device.c \
- libkms-test-framebuffer.c \
- libkms-test-plane.c \
- libkms-test-screen.c
-
-libkms_test_la_LIBADD = \
- $(top_builddir)/libdrm.la
-
-if HAVE_INSTALL_TESTS
-bin_PROGRAMS = \
- kms-steal-crtc \
- kms-universal-planes
-else
-noinst_PROGRAMS = \
- kms-steal-crtc \
- kms-universal-planes
-endif
-
-kms_steal_crtc_SOURCES = kms-steal-crtc.c
-kms_steal_crtc_LDADD = libkms-test.la ../util/libutil.la $(CAIRO_LIBS)
-
-kms_universal_planes_SOURCES = kms-universal-planes.c
-kms_universal_planes_LDADD = libkms-test.la $(CAIRO_LIBS)
diff --git a/tests/kmstest/Makefile.am b/tests/kmstest/Makefile.am
deleted file mode 100644
index ced541b..0000000
--- a/tests/kmstest/Makefile.am
+++ /dev/null
@@ -1,25 +0,0 @@
-AM_CFLAGS = \
- $(WARN_CFLAGS)\
- -I$(top_srcdir)/include/drm \
- -I$(top_srcdir)/libkms/ \
- -I$(top_srcdir)/tests/ \
- -I$(top_srcdir)
-
-if HAVE_INSTALL_TESTS
-bin_PROGRAMS = \
- kmstest
-else
-noinst_PROGRAMS = \
- kmstest
-endif
-
-kmstest_SOURCES = \
- main.c
-
-kmstest_LDADD = \
- $(top_builddir)/tests/util/libutil.la \
- $(top_builddir)/libkms/libkms.la \
- $(top_builddir)/libdrm.la
-
-run: kmstest
- ./kmstest
diff --git a/tests/modeprint/Makefile.am b/tests/modeprint/Makefile.am
deleted file mode 100644
index 601dbc9..0000000
--- a/tests/modeprint/Makefile.am
+++ /dev/null
@@ -1,18 +0,0 @@
-AM_CFLAGS = \
- $(WARN_CFLAGS)\
- -I$(top_srcdir)/include/drm \
- -I$(top_srcdir)/tests \
- -I$(top_srcdir)
-
-if HAVE_INSTALL_TESTS
-bin_PROGRAMS = \
- modeprint
-else
-noinst_PROGRAMS = \
- modeprint
-endif
-
-modeprint_SOURCES = \
- modeprint.c
-modeprint_LDADD = \
- $(top_builddir)/libdrm.la
diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am
deleted file mode 100644
index 4b296c8..0000000
--- a/tests/modetest/Makefile.am
+++ /dev/null
@@ -1,24 +0,0 @@
-include Makefile.sources
-
-AM_CFLAGS = $(filter-out -Wpointer-arith, $(WARN_CFLAGS))
-
-AM_CFLAGS += \
- -pthread \
- -I$(top_srcdir)/include/drm \
- -I$(top_srcdir)/tests \
- -I$(top_srcdir)
-
-if HAVE_INSTALL_TESTS
-bin_PROGRAMS = \
- modetest
-else
-noinst_PROGRAMS = \
- modetest
-endif
-
-modetest_SOURCES = $(MODETEST_FILES)
-
-modetest_LDADD = \
- $(top_builddir)/libdrm.la \
- $(top_builddir)/tests/util/libutil.la \
- $(CAIRO_LIBS)
diff --git a/tests/modetest/Makefile.sources b/tests/modetest/Makefile.sources
deleted file mode 100644
index 399af0d..0000000
--- a/tests/modetest/Makefile.sources
+++ /dev/null
@@ -1,6 +0,0 @@
-MODETEST_FILES := \
- buffers.c \
- buffers.h \
- cursor.c \
- cursor.h \
- modetest.c
diff --git a/tests/nouveau/Makefile.am b/tests/nouveau/Makefile.am
deleted file mode 100644
index 3c799a8..0000000
--- a/tests/nouveau/Makefile.am
+++ /dev/null
@@ -1,16 +0,0 @@
-AM_CFLAGS = \
- -pthread \
- $(WARN_CFLAGS) \
- -I$(top_srcdir)/include/drm \
- -I$(top_srcdir)/nouveau \
- -I$(top_srcdir)
-
-LDADD = \
- ../../nouveau/libdrm_nouveau.la \
- ../../libdrm.la \
- -ldl
-
-TESTS = threaded
-
-check_PROGRAMS = $(TESTS)
-
diff --git a/tests/proptest/Makefile.am b/tests/proptest/Makefile.am
deleted file mode 100644
index 3fde46b..0000000
--- a/tests/proptest/Makefile.am
+++ /dev/null
@@ -1,21 +0,0 @@
-include Makefile.sources
-
-AM_CFLAGS = \
- $(WARN_CFLAGS)\
- -I$(top_srcdir)/include/drm \
- -I$(top_srcdir)/tests \
- -I$(top_srcdir)
-
-if HAVE_INSTALL_TESTS
-bin_PROGRAMS = \
- proptest
-else
-noinst_PROGRAMS = \
- proptest
-endif
-
-proptest_SOURCES = $(PROPTEST_FILES)
-
-proptest_LDADD = \
- $(top_builddir)/libdrm.la \
- $(top_builddir)/tests/util/libutil.la
diff --git a/tests/proptest/Makefile.sources b/tests/proptest/Makefile.sources
deleted file mode 100644
index 446110d..0000000
--- a/tests/proptest/Makefile.sources
+++ /dev/null
@@ -1,2 +0,0 @@
-PROPTEST_FILES := \
- proptest.c
diff --git a/tests/radeon/Makefile.am b/tests/radeon/Makefile.am
deleted file mode 100644
index 9da7625..0000000
--- a/tests/radeon/Makefile.am
+++ /dev/null
@@ -1,14 +0,0 @@
-AM_CFLAGS = \
- $(WARN_CFLAGS)\
- -I $(top_srcdir)/include/drm \
- -I $(top_srcdir)
-
-LDADD = $(top_builddir)/libdrm.la
-
-noinst_PROGRAMS = \
- radeon_ttm
-
-radeon_ttm_SOURCES = \
- rbo.c \
- rbo.h \
- radeon_ttm.c
diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am
deleted file mode 100644
index 8e625c8..0000000
--- a/tests/tegra/Makefile.am
+++ /dev/null
@@ -1,13 +0,0 @@
-AM_CPPFLAGS = \
- -I$(top_srcdir)/include/drm \
- -I$(top_srcdir)/tegra \
- -I$(top_srcdir)
-
-AM_CFLAGS = $(WARN_CFLAGS)
-
-LDADD = \
- ../../tegra/libdrm_tegra.la \
- ../../libdrm.la
-
-noinst_PROGRAMS = \
- openclose
diff --git a/tests/ttmtest/Makefile.am b/tests/ttmtest/Makefile.am
deleted file mode 100644
index af437a6..0000000
--- a/tests/ttmtest/Makefile.am
+++ /dev/null
@@ -1 +0,0 @@
-SUBDIRS = src
diff --git a/tests/ttmtest/src/Makefile.am b/tests/ttmtest/src/Makefile.am
deleted file mode 100644
index b7ee829..0000000
--- a/tests/ttmtest/src/Makefile.am
+++ /dev/null
@@ -1,8 +0,0 @@
-INCLUDES = @MDRIINC@
-bin_PROGRAMS = ttmtest
-ttmtest_SOURCES = \
- ttmtest.c \
- xf86dri.c \
- xf86dri.h \
- xf86dristr.h
-ttmtest_LDADD = -ldrm -lXext -lX11
diff --git a/tests/util/Makefile.am b/tests/util/Makefile.am
deleted file mode 100644
index f8e0b17..0000000
--- a/tests/util/Makefile.am
+++ /dev/null
@@ -1,13 +0,0 @@
-include Makefile.sources
-
-noinst_LTLIBRARIES = \
- libutil.la
-
-libutil_la_CPPFLAGS = \
- -I$(top_srcdir)/include/drm \
- -I$(top_srcdir)
-
-libutil_la_CFLAGS = \
- $(CAIRO_CFLAGS)
-
-libutil_la_SOURCES = $(UTIL_FILES)
diff --git a/tests/util/Makefile.sources b/tests/util/Makefile.sources
deleted file mode 100644
index e5f8511..0000000
--- a/tests/util/Makefile.sources
+++ /dev/null
@@ -1,8 +0,0 @@
-UTIL_FILES := \
- common.h \
- format.c \
- format.h \
- kms.c \
- kms.h \
- pattern.c \
- pattern.h
diff --git a/tests/vbltest/Makefile.am b/tests/vbltest/Makefile.am
deleted file mode 100644
index 276afad..0000000
--- a/tests/vbltest/Makefile.am
+++ /dev/null
@@ -1,19 +0,0 @@
-AM_CFLAGS = \
- $(WARN_CFLAGS)\
- -I$(top_srcdir)/include/drm \
- -I$(top_srcdir)/tests \
- -I$(top_srcdir)
-
-if HAVE_INSTALL_TESTS
-bin_PROGRAMS = \
- vbltest
-else
-noinst_PROGRAMS = \
- vbltest
-endif
-
-vbltest_SOURCES = \
- vbltest.c
-vbltest_LDADD = \
- $(top_builddir)/libdrm.la \
- $(top_builddir)/tests/util/libutil.la
diff --git a/vc4/Makefile.am b/vc4/Makefile.am
deleted file mode 100644
index 7e486b4..0000000
--- a/vc4/Makefile.am
+++ /dev/null
@@ -1,34 +0,0 @@
-# Copyright © 2016 Broadcom
-#
-# Permission is hereby granted, free of charge, to any person obtaining a
-# copy of this software and associated documentation files (the "Software"),
-# to deal in the Software without restriction, including without limitation
-# the rights to use, copy, modify, merge, publish, distribute, sublicense,
-# and/or sell copies of the Software, and to permit persons to whom the
-# Software is furnished to do so, subject to the following conditions:
-#
-# The above copyright notice and this permission notice (including the next
-# paragraph) shall be included in all copies or substantial portions of the
-# Software.
-#
-# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
-# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
-# IN THE SOFTWARE.
-
-include Makefile.sources
-
-AM_CFLAGS = \
- $(WARN_CFLAGS) \
- -I$(top_srcdir) \
- $(PTHREADSTUBS_CFLAGS) \
- $(VALGRIND_CFLAGS) \
- -I$(top_srcdir)/include/drm
-
-libdrm_vc4includedir = ${includedir}/libdrm
-libdrm_vc4include_HEADERS = $(LIBDRM_VC4_H_FILES)
-
-pkgconfig_DATA = libdrm_vc4.pc
diff --git a/vc4/Makefile.sources b/vc4/Makefile.sources
deleted file mode 100644
index 8bf97ff..0000000
--- a/vc4/Makefile.sources
+++ /dev/null
@@ -1,3 +0,0 @@
-LIBDRM_VC4_H_FILES := \
- vc4_packet.h \
- vc4_qpu_defines.h
diff --git a/vc4/libdrm_vc4.pc.in b/vc4/libdrm_vc4.pc.in
deleted file mode 100644
index a92678e..0000000
--- a/vc4/libdrm_vc4.pc.in
+++ /dev/null
@@ -1,9 +0,0 @@
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: libdrm_vc4
-Description: Userspace interface to vc4 kernel DRM services
-Version: @PACKAGE_VERSION@
-Requires.private: libdrm
--
git-series 0.9.1
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-16 21:25 [RFC libdrm 0/2] Replace the build system with meson Dylan Baker
2017-03-16 21:25 ` [RFC libdrm 1/2] Port build system to meson Dylan Baker
2017-03-16 21:25 ` [RFC libdrm 2/2] remove autotools build Dylan Baker
@ 2017-03-16 21:32 ` Ilia Mirkin
2017-03-16 21:57 ` Dylan Baker
2017-03-16 22:36 ` Marek Olšák
` (4 subsequent siblings)
7 siblings, 1 reply; 94+ messages in thread
From: Ilia Mirkin @ 2017-03-16 21:32 UTC (permalink / raw)
To: Dylan Baker; +Cc: mesa-dev, dri-devel
On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
> Why bother, and why would we want this? │~
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently. Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
>
> What's different about using meson?
>
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D<opt>=<value> more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?
>
> Here are the performance numbers I see on a 2 core 4 thread SKL, without
> initial configuration, and building out of tree (using zsh):
>
> For meson the command line is:
> time (meson build -Dmanpages=true && ninja -C build)
>
> For autotools the command line is:
> time (mdkir build && cd build && ../autotools && make -j5 -l4)<Paste>
Probably mkdir...
>
> meson (cold ccache): 13.37s user 1.74s system 255% cpu 5.907 total
> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> meson (hot ccache): 2.13s user 0.39s system 154% cpu 1.633 total
> autotools (hot ccache): 13.93s user 0.73s system 102% cpu 14.259 total
>
> That's ~4x faster for a cold build and ~10x faster for a hot build.
>
> For a make clean && make style build with a hot cache:
> meson: 4.64s user 0.33s system 334% cpu 1.486 total
> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>
> Why bother with libdrm?
>
> It's a simple build system, that could be completely (or mostly
> completely) be ported in a very short time, and could serve as a tech
> demo for the advantages of using meson to garner feedback for embarking
> on a larger project, like mesa (which is what I'm planning to work on
> next).
>
> tl;dr
>
> I wrote this as practice for porting Mesa, and figured I might as well
> send it out since I wrote it.
>
> It is very likely that neither of these large patches will show up on the
> mailing list, but this is available at my github:
> https://github.com/dcbaker/libdrm wip/meson
I haven't looked at meson or your patches in detail, but autotools
supports 2 very important use-cases very well:
1. ./configure --help
2. Cross-compilation with minimal requirement from the project being built
Can you comment on how these are handled in meson?
Cheers,
-ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-16 21:32 ` [RFC libdrm 0/2] Replace the build system with meson Ilia Mirkin
@ 2017-03-16 21:57 ` Dylan Baker
2017-03-17 10:05 ` Neil Armstrong
0 siblings, 1 reply; 94+ messages in thread
From: Dylan Baker @ 2017-03-16 21:57 UTC (permalink / raw)
To: Ilia Mirkin; +Cc: mesa-dev, dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 4671 bytes --]
Quoting Ilia Mirkin (2017-03-16 14:32:09)
> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
> > Why bother, and why would we want this? │~
> >
> > First it's written in python, which means the potential developer base
> > is massive. And it provides a recursive view for humans, but a
> > non-recursive view for the system. This is the best of both worlds,
> > humans can organize the build system in a way that makes sense, and the
> > machine gets a non-recursive build system. It also uses ninja rather
> > than make, and ninja is faster than make inherently. Meson is also a
> > simpler syntax than autotools or cmake it's not Turing Complete by
> > design nor does it expose python, again, by design. This allows meson
> > itself to be reimplemented in a another language if python becomes a
> > dead-end or a bottle-neck. It also makes it much easier to understand
> > what the build system is doing.
> >
> > What's different about using meson?
> >
> > Well, apart from a faster builds and less magic in the build system? The
> > configure flags are different, it uses -D<opt>=<value> more like cmake
> > than the --enable or --with flags of autotools, although oddly it uses
> > --prefix and friends when calling meson, but not with mesonconf, there's
> > a bug opened on this. Meson also doesn't support in-tree builds at all;
> > all builds are done out of tree. It also doesn't provide a "make dist"
> > target, fortunately there's this awesome tool called git, and it
> > provides a "git archive" command that does much the same thing. Did I
> > mention it's fast?
> >
> > Here are the performance numbers I see on a 2 core 4 thread SKL, without
> > initial configuration, and building out of tree (using zsh):
> >
> > For meson the command line is:
> > time (meson build -Dmanpages=true && ninja -C build)
> >
> > For autotools the command line is:
> > time (mdkir build && cd build && ../autotools && make -j5 -l4)<Paste>
>
> Probably mkdir...
derp, yeah.
>
> >
> > meson (cold ccache): 13.37s user 1.74s system 255% cpu 5.907 total
> > autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> > meson (hot ccache): 2.13s user 0.39s system 154% cpu 1.633 total
> > autotools (hot ccache): 13.93s user 0.73s system 102% cpu 14.259 total
> >
> > That's ~4x faster for a cold build and ~10x faster for a hot build.
> >
> > For a make clean && make style build with a hot cache:
> > meson: 4.64s user 0.33s system 334% cpu 1.486 total
> > autotools: 7.93s user 0.32s system 167% cpu 4.920 total
> >
> > Why bother with libdrm?
> >
> > It's a simple build system, that could be completely (or mostly
> > completely) be ported in a very short time, and could serve as a tech
> > demo for the advantages of using meson to garner feedback for embarking
> > on a larger project, like mesa (which is what I'm planning to work on
> > next).
> >
> > tl;dr
> >
> > I wrote this as practice for porting Mesa, and figured I might as well
> > send it out since I wrote it.
> >
> > It is very likely that neither of these large patches will show up on the
> > mailing list, but this is available at my github:
> > https://github.com/dcbaker/libdrm wip/meson
>
> I haven't looked at meson or your patches in detail, but autotools
> supports 2 very important use-cases very well:
>
> 1. ./configure --help
> 2. Cross-compilation with minimal requirement from the project being built
>
> Can you comment on how these are handled in meson?
>
> Cheers,
>
> -ilia
1. mesonconf <builddir> provides much the same thing. You can also read the
meson_options.txt file, which is generally pretty short. I haven't added
descriptions to the options in this patch.
2. you write a small ini style configuration file, something like:
[binaries]
c = '/usr/bin/aarch64-linux-gnu-gc'
ar = '/usr/bin/aarch64-linux-gnu-gcc-ar'
strip = '/usr/bin/aarch64-linux-gnu-strip'
pkg-config = '/usr/bin/aarch64-linux-gnu-pkgconfig'
Then you just configure with:
meson build --cross-file cross_file.txt
then just ninja like normal
There's a more detailed walkthrough here:
https://github.com/mesonbuild/meson/wiki/Cross-compilation
I was able to cross compile the arm libraries for aarch64 using basically the
above configuration (I had to write a wrapper script for pkg-config to set a
couple of environment variables and install and archlinux aarach64 chroot,
because arch), of course, I don't have access to any arm machines that I could
test with.
Dylan
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljLCk4ACgkQCJ4WlhQG
iO/aXAf5Aa24b7MDG7XXZEgnjfc7fWw4QtArtz06mUX2srCm7Y9ojT2YjCp9dGkz
vCr5NHcXFExHMl6aUDKkAR3a/pXzG1/iV6I48X2JoKdOfwIG6UnOiv8BU8rZWcbn
I8yLTUWeO2cC3mMPLm2dDAqwA8XCi+GhdgoOou0gMgBBgKPlDmRD8Glno7bJt0ex
vKWYE4jvPj3exCdArX+RN+t2BRITWY9cIK7ivQrWiVcsQvuqbDb2wNTpa4ivrFGb
Pr6Uv4eNOv7H9OkOJITyVRk2p+ULv5NoVR/bmCe2tWZY8AmPNQOH82hqOO4ozXA8
fbDKKlMdZP19K1uj3CPvIiYZujH24g==
=yiYj
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-16 21:25 [RFC libdrm 0/2] Replace the build system with meson Dylan Baker
` (2 preceding siblings ...)
2017-03-16 21:32 ` [RFC libdrm 0/2] Replace the build system with meson Ilia Mirkin
@ 2017-03-16 22:36 ` Marek Olšák
2017-03-16 23:11 ` Dylan Baker
2017-03-22 17:26 ` Jose Fonseca
2017-03-16 23:35 ` Emil Velikov
` (3 subsequent siblings)
7 siblings, 2 replies; 94+ messages in thread
From: Marek Olšák @ 2017-03-16 22:36 UTC (permalink / raw)
To: Dylan Baker; +Cc: mesa-dev, dri-devel
Is there a way not to use ninja with meson, because ninja redirects
all stderr output from gcc to stdout, which breaks many development
environments that expect errors in stderr?
I'm basically saying that if ninja can't keep gcc errors in stderr, I
wouldn't like any project that I might be involved in to require ninja
for building.
Marek
On Thu, Mar 16, 2017 at 10:25 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
> Why bother, and why would we want this? │~
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently. Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
>
> What's different about using meson?
>
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D<opt>=<value> more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?
>
> Here are the performance numbers I see on a 2 core 4 thread SKL, without
> initial configuration, and building out of tree (using zsh):
>
> For meson the command line is:
> time (meson build -Dmanpages=true && ninja -C build)
>
> For autotools the command line is:
> time (mdkir build && cd build && ../autotools && make -j5 -l4)<Paste>
>
> meson (cold ccache): 13.37s user 1.74s system 255% cpu 5.907 total
> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> meson (hot ccache): 2.13s user 0.39s system 154% cpu 1.633 total
> autotools (hot ccache): 13.93s user 0.73s system 102% cpu 14.259 total
>
> That's ~4x faster for a cold build and ~10x faster for a hot build.
>
> For a make clean && make style build with a hot cache:
> meson: 4.64s user 0.33s system 334% cpu 1.486 total
> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>
> Why bother with libdrm?
>
> It's a simple build system, that could be completely (or mostly
> completely) be ported in a very short time, and could serve as a tech
> demo for the advantages of using meson to garner feedback for embarking
> on a larger project, like mesa (which is what I'm planning to work on
> next).
>
> tl;dr
>
> I wrote this as practice for porting Mesa, and figured I might as well
> send it out since I wrote it.
>
> It is very likely that neither of these large patches will show up on the
> mailing list, but this is available at my github:
> https://github.com/dcbaker/libdrm wip/meson
>
> Dylan Baker (2):
> Port build system to meson
> remove autotools build
>
> .editorconfig | 2 +-
> .gitignore | 82 +-----
> Makefile.am | 144 +--------
> Makefile.sources | 41 +--
> README | 21 +-
> amdgpu/Makefile.am | 47 +---
> amdgpu/Makefile.sources | 15 +-
> amdgpu/libdrm_amdgpu.pc.in | 11 +-
> amdgpu/meson.build | 57 +++-
> autogen.sh | 20 +-
> configure.ac | 568 +--------------------------------
> etnaviv/Makefile.am | 26 +-
> etnaviv/Makefile.sources | 12 +-
> etnaviv/libdrm_etnaviv.pc.in | 11 +-
> etnaviv/meson.build | 56 +++-
> exynos/Makefile.am | 27 +--
> exynos/libdrm_exynos.pc.in | 11 +-
> exynos/meson.build | 52 +++-
> freedreno/Makefile.am | 30 +--
> freedreno/Makefile.sources | 26 +-
> freedreno/libdrm_freedreno.pc.in | 11 +-
> freedreno/meson.build | 72 ++++-
> include/drm/meson.build | 48 +++-
> intel/Makefile.am | 73 +----
> intel/Makefile.sources | 15 +-
> intel/intel_bufmgr_gem.c | 8 +-
> intel/libdrm_intel.pc.in | 11 +-
> intel/meson.build | 55 +++-
> libdrm.pc.in | 10 +-
> libkms/Makefile.am | 43 +--
> libkms/Makefile.sources | 23 +-
> libkms/libkms.pc.in | 11 +-
> libkms/meson.build | 71 ++++-
> m4/.gitignore | 5 +-
> man/Makefile.am | 62 +---
> man/meson.build | 119 +++++++-
> meson.build | 288 ++++++++++++++++-
> meson_config.h.in | 24 +-
> meson_options.txt | 16 +-
> nouveau/Makefile.am | 33 +--
> nouveau/Makefile.sources | 9 +-
> nouveau/libdrm_nouveau.pc.in | 11 +-
> nouveau/meson.build | 63 ++++-
> omap/Makefile.am | 24 +-
> omap/libdrm_omap.pc.in | 11 +-
> omap/meson.build | 48 +++-
> radeon/Makefile.am | 47 +---
> radeon/Makefile.sources | 21 +-
> radeon/libdrm_radeon.pc.in | 11 +-
> radeon/meson.build | 62 +++-
> tegra/Makefile.am | 25 +-
> tegra/libdrm_tegra.pc.in | 11 +-
> tegra/meson.build | 50 +++-
> tests/Makefile.am | 47 +---
> tests/amdgpu/Makefile.am | 29 +--
> tests/amdgpu/meson.build | 30 ++-
> tests/etnaviv/Makefile.am | 41 +--
> tests/etnaviv/meson.build | 49 +++-
> tests/exynos/Makefile.am | 47 +---
> tests/exynos/meson.build | 43 ++-
> tests/kms/Makefile.am | 36 +--
> tests/kms/meson.build | 46 +++-
> tests/kmstest/Makefile.am | 25 +-
> tests/kmstest/meson.build | 28 ++-
> tests/meson.build | 87 +++++-
> tests/modeprint/Makefile.am | 18 +-
> tests/modeprint/meson.build | 27 ++-
> tests/modetest/Makefile.am | 24 +-
> tests/modetest/Makefile.sources | 6 +-
> tests/modetest/meson.build | 27 ++-
> tests/nouveau/Makefile.am | 16 +-
> tests/nouveau/meson.build | 30 ++-
> tests/proptest/Makefile.am | 21 +-
> tests/proptest/Makefile.sources | 2 +-
> tests/proptest/meson.build | 27 ++-
> tests/radeon/Makefile.am | 14 +-
> tests/radeon/meson.build | 27 ++-
> tests/tegra/Makefile.am | 13 +-
> tests/tegra/meson.build | 27 ++-
> tests/ttmtest/Makefile.am | 1 +-
> tests/ttmtest/src/Makefile.am | 8 +-
> tests/util/Makefile.am | 13 +-
> tests/util/Makefile.sources | 8 +-
> tests/util/meson.build | 35 ++-
> tests/vbltest/Makefile.am | 19 +-
> tests/vbltest/meson.build | 27 ++-
> vc4/Makefile.am | 34 +--
> vc4/Makefile.sources | 3 +-
> vc4/libdrm_vc4.pc.in | 9 +-
> vc4/meson.build | 28 ++-
> xf86atomic.h | 4 +-
> 91 files changed, 1634 insertions(+), 1992 deletions(-)
> delete mode 100644 Makefile.am
> delete mode 100644 Makefile.sources
> delete mode 100644 amdgpu/Makefile.am
> delete mode 100644 amdgpu/Makefile.sources
> delete mode 100644 amdgpu/libdrm_amdgpu.pc.in
> create mode 100644 amdgpu/meson.build
> delete mode 100755 autogen.sh
> delete mode 100644 configure.ac
> delete mode 100644 etnaviv/Makefile.am
> delete mode 100644 etnaviv/Makefile.sources
> delete mode 100644 etnaviv/libdrm_etnaviv.pc.in
> create mode 100644 etnaviv/meson.build
> delete mode 100644 exynos/Makefile.am
> delete mode 100644 exynos/libdrm_exynos.pc.in
> create mode 100644 exynos/meson.build
> delete mode 100644 freedreno/Makefile.am
> delete mode 100644 freedreno/Makefile.sources
> delete mode 100644 freedreno/libdrm_freedreno.pc.in
> create mode 100644 freedreno/meson.build
> create mode 100644 include/drm/meson.build
> delete mode 100644 intel/Makefile.am
> delete mode 100644 intel/Makefile.sources
> delete mode 100644 intel/libdrm_intel.pc.in
> create mode 100644 intel/meson.build
> delete mode 100644 libdrm.pc.in
> delete mode 100644 libkms/Makefile.am
> delete mode 100644 libkms/Makefile.sources
> delete mode 100644 libkms/libkms.pc.in
> create mode 100644 libkms/meson.build
> delete mode 100644 m4/.gitignore
> delete mode 100644 man/Makefile.am
> create mode 100644 man/meson.build
> create mode 100644 meson.build
> create mode 100644 meson_config.h.in
> create mode 100644 meson_options.txt
> delete mode 100644 nouveau/Makefile.am
> delete mode 100644 nouveau/Makefile.sources
> delete mode 100644 nouveau/libdrm_nouveau.pc.in
> create mode 100644 nouveau/meson.build
> delete mode 100644 omap/Makefile.am
> delete mode 100644 omap/libdrm_omap.pc.in
> create mode 100644 omap/meson.build
> delete mode 100644 radeon/Makefile.am
> delete mode 100644 radeon/Makefile.sources
> delete mode 100644 radeon/libdrm_radeon.pc.in
> create mode 100644 radeon/meson.build
> delete mode 100644 tegra/Makefile.am
> delete mode 100644 tegra/libdrm_tegra.pc.in
> create mode 100644 tegra/meson.build
> delete mode 100644 tests/Makefile.am
> delete mode 100644 tests/amdgpu/Makefile.am
> create mode 100644 tests/amdgpu/meson.build
> delete mode 100644 tests/etnaviv/Makefile.am
> create mode 100644 tests/etnaviv/meson.build
> delete mode 100644 tests/exynos/Makefile.am
> create mode 100644 tests/exynos/meson.build
> delete mode 100644 tests/kms/Makefile.am
> create mode 100644 tests/kms/meson.build
> delete mode 100644 tests/kmstest/Makefile.am
> create mode 100644 tests/kmstest/meson.build
> create mode 100644 tests/meson.build
> delete mode 100644 tests/modeprint/Makefile.am
> create mode 100644 tests/modeprint/meson.build
> delete mode 100644 tests/modetest/Makefile.am
> delete mode 100644 tests/modetest/Makefile.sources
> create mode 100644 tests/modetest/meson.build
> delete mode 100644 tests/nouveau/Makefile.am
> create mode 100644 tests/nouveau/meson.build
> delete mode 100644 tests/proptest/Makefile.am
> delete mode 100644 tests/proptest/Makefile.sources
> create mode 100644 tests/proptest/meson.build
> delete mode 100644 tests/radeon/Makefile.am
> create mode 100644 tests/radeon/meson.build
> delete mode 100644 tests/tegra/Makefile.am
> create mode 100644 tests/tegra/meson.build
> delete mode 100644 tests/ttmtest/Makefile.am
> delete mode 100644 tests/ttmtest/src/Makefile.am
> delete mode 100644 tests/util/Makefile.am
> delete mode 100644 tests/util/Makefile.sources
> create mode 100644 tests/util/meson.build
> delete mode 100644 tests/vbltest/Makefile.am
> create mode 100644 tests/vbltest/meson.build
> delete mode 100644 vc4/Makefile.am
> delete mode 100644 vc4/Makefile.sources
> delete mode 100644 vc4/libdrm_vc4.pc.in
> create mode 100644 vc4/meson.build
>
> base-commit: 19c4cfc54918d361f2535aec16650e9f0be667cd
> --
> git-series 0.9.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-16 22:36 ` Marek Olšák
@ 2017-03-16 23:11 ` Dylan Baker
2017-03-17 1:53 ` Marek Olšák
2017-03-22 17:26 ` Jose Fonseca
1 sibling, 1 reply; 94+ messages in thread
From: Dylan Baker @ 2017-03-16 23:11 UTC (permalink / raw)
To: Marek Olšák; +Cc: mesa-dev, dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 816 bytes --]
Quoting Marek Olšák (2017-03-16 15:36:26)
> Is there a way not to use ninja with meson, because ninja redirects
> all stderr output from gcc to stdout, which breaks many development
> environments that expect errors in stderr?
>
> I'm basically saying that if ninja can't keep gcc errors in stderr, I
> wouldn't like any project that I might be involved in to require ninja
> for building.
>
> Marek
There is no way to use another backend on Linux, and meson will not support
Make. Ninja is a big part of the appeal here, since it is faster than make is.
Are there particular tools you know don't work with ninja? It seems like in the
7+ years since ninja came out that someone would have fixed the tools, or that
some stream redirection could be used to fix the problem, "ninja 1>&2"?
Dylan
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljLG7QACgkQCJ4WlhQG
iO8vtwf9G+lp0ry6a+xSoIEiBjw7ZvMjwG8pBRRAPVye1jq1DXBoj2T8G6G/898z
ermxde9Nl+tekGq5m8pw+YfIEcJYLrFwyr132xNP1BnALwzmKNBRA+JktCsUgOly
YnfNulLeUf3zbdTykMps76I7vonC896AmQSupm3p4XwvfnzAIjohtx9nk2jxIGGL
nENiPgfgyLEf46oK5P1gbFaX5SQnEqKV3FMcJYDyO4ByCdBlZbcmib4IOqjDZrut
+iMcJBY76ifwVVkDjq1c/bYXuDDwuikgIFsmmZQRBE4ocebhfqWOAHmYgImkybOv
C6e2MqdljCJ6DDLDCTrJnI2w15FIQQ==
=dvyi
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-16 21:25 [RFC libdrm 0/2] Replace the build system with meson Dylan Baker
` (3 preceding siblings ...)
2017-03-16 22:36 ` Marek Olšák
@ 2017-03-16 23:35 ` Emil Velikov
2017-03-17 0:21 ` Dylan Baker
2017-03-21 14:44 ` Jani Nikula
` (2 subsequent siblings)
7 siblings, 1 reply; 94+ messages in thread
From: Emil Velikov @ 2017-03-16 23:35 UTC (permalink / raw)
To: Dylan Baker; +Cc: ML mesa-dev, ML dri-devel
Hi Dylan,
On 16 March 2017 at 21:25, Dylan Baker <dylan@pnwbakers.com> wrote:
> Why bother, and why would we want this? │~
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently. Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
>
> What's different about using meson?
>
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D<opt>=<value> more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?
>
> Here are the performance numbers I see on a 2 core 4 thread SKL, without
> initial configuration, and building out of tree (using zsh):
>
> For meson the command line is:
> time (meson build -Dmanpages=true && ninja -C build)
>
> For autotools the command line is:
> time (mdkir build && cd build && ../autotools && make -j5 -l4)<Paste>
>
> meson (cold ccache): 13.37s user 1.74s system 255% cpu 5.907 total
> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> meson (hot ccache): 2.13s user 0.39s system 154% cpu 1.633 total
> autotools (hot ccache): 13.93s user 0.73s system 102% cpu 14.259 total
>
> That's ~4x faster for a cold build and ~10x faster for a hot build.
>
> For a make clean && make style build with a hot cache:
> meson: 4.64s user 0.33s system 334% cpu 1.486 total
> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>
> Why bother with libdrm?
>
> It's a simple build system, that could be completely (or mostly
> completely) be ported in a very short time, and could serve as a tech
> demo for the advantages of using meson to garner feedback for embarking
> on a larger project, like mesa (which is what I'm planning to work on
> next).
>
> tl;dr
>
> I wrote this as practice for porting Mesa, and figured I might as well
> send it out since I wrote it.
>
> It is very likely that neither of these large patches will show up on the
> mailing list, but this is available at my github:
> https://github.com/dcbaker/libdrm wip/meson
>
While I can see you're impressed by Meson, I would kindly urge you to
not use it here. As you look closely you can see that one could
trivially improve the times, yet the biggest thing is that most of the
code in libdrm must go ;-)
As the port is not 1:1 wrt the autoconf one, the performance numbers
above are comparing apples to oranges.
If you/others are unhappy with the build times of libdrm - poke me on
IRC. I will give you some easy tips on how to improve those.
You have some good python knowledge - I would kindly urge you to
improve/rewrite the slow and/or hacky python scripts we have in mesa.
This is a topic that was mentioned multiple times, and a part where
everyone will be glad to see some progress.
Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-16 23:35 ` Emil Velikov
@ 2017-03-17 0:21 ` Dylan Baker
2017-03-17 0:41 ` Emil Velikov
0 siblings, 1 reply; 94+ messages in thread
From: Dylan Baker @ 2017-03-17 0:21 UTC (permalink / raw)
To: Emil Velikov; +Cc: ML mesa-dev, ML dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 2147 bytes --]
Hi Emil,
Quoting Emil Velikov (2017-03-16 16:35:33)
> While I can see you're impressed by Meson, I would kindly urge you to
> not use it here. As you look closely you can see that one could
> trivially improve the times, yet the biggest thing is that most of the
> code in libdrm must go ;-)
Perhaps I wasn't clear enough, I don't really expect this to land ever. I sent
it out more because I'd written it and it works and is a useful demonstration of
meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge deal :);
but in a larger project, consider that a 4x speedup would be 4 minutes to 1
minute, and that is a huge difference in time.
>
> As the port is not 1:1 wrt the autoconf one, the performance numbers
> above are comparing apples to oranges.
I fail to see what I'm missing from meson that would have an effect on the
times I reported. There are some files that are installed by autoconf that I
didn't bother to install with meson (because I don't expect this to land). Since
I didn't time installs, I don't see how it isn't an apples to apples comparison.
I understand that libdrm is a pessimal case for recursive-make since most
sub folders contain < 5 C files, However, even if you were to flatten the make
files meson+ninja would still be faster when you consider that meson
configures and builds faster than autotools configures.
> If you/others are unhappy with the build times of libdrm - poke me on
> IRC. I will give you some easy tips on how to improve those.
>
> You have some good python knowledge - I would kindly urge you to
> improve/rewrite the slow and/or hacky python scripts we have in mesa.
> This is a topic that was mentioned multiple times, and a part where
> everyone will be glad to see some progress.
>
> Thanks
> Emil
The real goal here is to do mesa (in case I didn't make that clear either), and
the advantage for mesa is not just performance, it's that meson supports visual
studio on windows; which means that we could hopefully not just get faster
builds, but also replace both autotools and scons with a single build system.
Dylan
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljLK/sACgkQCJ4WlhQG
iO/2LAf+I8bkBVSIl+NTMoJH6j/YReMAy0MppvDUde3bMqOjjdEZN/UaAWT4lVLU
4pIPmqB7RE3Iz/4JEpnAqpjJAZP5TF2iZSyWvPc/BXNRaGMVu0Tk/sVUQHS7wn3p
Zk2bVNAnznfvfRtwvxKtLklnwzDBRo9m7h4c46Fa5H8XHuAz/f0xdiAAcvlbJTE7
aTiS+XUfSF5hxQW8PglOLXN1nxzkD+ibyasrUnYTo02oX7dQHY+Gc34rnrqlHkmw
Ho3EDS1igo7I+/hl+mIxJoIPRnZQxlms90YKLAb/yodkn0yHG9BrV3RIeMNMj31y
BRjnUqgqrPjOgfkIBBrSIJ3qJDGuAA==
=tSh/
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-17 0:21 ` Dylan Baker
@ 2017-03-17 0:41 ` Emil Velikov
2017-03-17 2:03 ` Jason Ekstrand
0 siblings, 1 reply; 94+ messages in thread
From: Emil Velikov @ 2017-03-17 0:41 UTC (permalink / raw)
To: Dylan Baker; +Cc: ML mesa-dev, ML dri-devel
On 17 March 2017 at 00:21, Dylan Baker <dylan@pnwbakers.com> wrote:
> Hi Emil,
>
> Quoting Emil Velikov (2017-03-16 16:35:33)
>> While I can see you're impressed by Meson, I would kindly urge you to
>> not use it here. As you look closely you can see that one could
>> trivially improve the times, yet the biggest thing is that most of the
>> code in libdrm must go ;-)
>
> Perhaps I wasn't clear enough, I don't really expect this to land ever. I sent
> it out more because I'd written it and it works and is a useful demonstration of
> meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge deal :);
> but in a larger project, consider that a 4x speedup would be 4 minutes to 1
> minute, and that is a huge difference in time.
>
You are still failing to see past your usecase. As said before - if
there's any need to improve things say so.
Note that you simply cannot apply the 1000x speedup in any situation.
>>
>> As the port is not 1:1 wrt the autoconf one, the performance numbers
>> above are comparing apples to oranges.
>
> I fail to see what I'm missing from meson that would have an effect on the
> times I reported. There are some files that are installed by autoconf that I
> didn't bother to install with meson (because I don't expect this to land). Since
> I didn't time installs, I don't see how it isn't an apples to apples comparison.
>
You already (explicitly) mentioned some differences. Admittedly not a
deal breaker.
> I understand that libdrm is a pessimal case for recursive-make since most
> sub folders contain < 5 C files, However, even if you were to flatten the make
> files meson+ninja would still be faster when you consider that meson
> configures and builds faster than autotools configures.
>
That's correct. If is so concerned - they should slim down the configure.ac ;-)
>> If you/others are unhappy with the build times of libdrm - poke me on
>> IRC. I will give you some easy tips on how to improve those.
>>
>> You have some good python knowledge - I would kindly urge you to
>> improve/rewrite the slow and/or hacky python scripts we have in mesa.
>> This is a topic that was mentioned multiple times, and a part where
>> everyone will be glad to see some progress.
>>
>> Thanks
>> Emil
>
> The real goal here is to do mesa (in case I didn't make that clear either), and
> the advantage for mesa is not just performance, it's that meson supports visual
> studio on windows; which means that we could hopefully not just get faster
> builds, but also replace both autotools and scons with a single build system.
>
Yes that was more than clear. Yet it won't fly, I'm afraid.
The VMWare people like their SCons, and Meson is not a thing on
neither BSD(s), Solaris (and derivatives) nor Android :-\
If there's something "slow" say what/where and we can improve upon
things. You seems to be rewriting $world because someone sold you that
A is the holy grail.
I'll repeat my earlier request - your python skills/knowledge will be
greatly appreciated in existing parts of Mesa.
Speaking of which - you last work doesn't seem to have landed. What's
blocking it ?
Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-16 23:11 ` Dylan Baker
@ 2017-03-17 1:53 ` Marek Olšák
2017-03-17 4:15 ` Dylan Baker
0 siblings, 1 reply; 94+ messages in thread
From: Marek Olšák @ 2017-03-17 1:53 UTC (permalink / raw)
To: Dylan Baker; +Cc: mesa-dev, dri-devel
On Fri, Mar 17, 2017 at 12:11 AM, Dylan Baker <dylan@pnwbakers.com> wrote:
> Quoting Marek Olšák (2017-03-16 15:36:26)
>> Is there a way not to use ninja with meson, because ninja redirects
>> all stderr output from gcc to stdout, which breaks many development
>> environments that expect errors in stderr?
>>
>> I'm basically saying that if ninja can't keep gcc errors in stderr, I
>> wouldn't like any project that I might be involved in to require ninja
>> for building.
>>
>> Marek
>
> There is no way to use another backend on Linux, and meson will not support
> Make. Ninja is a big part of the appeal here, since it is faster than make is.
> Are there particular tools you know don't work with ninja? It seems like in the
> 7+ years since ninja came out that someone would have fixed the tools, or that
> some stream redirection could be used to fix the problem, "ninja 1>&2"?
I actually read some thread about it and the conclusion seemed to be
that ninja developers don't care. I have no other option than to
believe that ninja was made for automated build bots, not for
development.
Some editors expect that errors and only errors go to stderr and all
other garbage info goes to stdout. This is something I can't change.
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-17 0:41 ` Emil Velikov
@ 2017-03-17 2:03 ` Jason Ekstrand
2017-03-17 2:28 ` Brian Paul
` (2 more replies)
0 siblings, 3 replies; 94+ messages in thread
From: Jason Ekstrand @ 2017-03-17 2:03 UTC (permalink / raw)
To: Emil Velikov, Dylan Baker; +Cc: ML mesa-dev, ML dri-devel
On March 16, 2017 5:41:24 PM Emil Velikov <emil.l.velikov@gmail.com> wrote:
> On 17 March 2017 at 00:21, Dylan Baker <dylan@pnwbakers.com> wrote:
>> Hi Emil,
>>
>> Quoting Emil Velikov (2017-03-16 16:35:33)
>>> While I can see you're impressed by Meson, I would kindly urge you to
>>> not use it here. As you look closely you can see that one could
>>> trivially improve the times, yet the biggest thing is that most of the
>>> code in libdrm must go ;-)
>>
>> Perhaps I wasn't clear enough, I don't really expect this to land ever. I sent
>> it out more because I'd written it and it works and is a useful
>> demonstration of
>> meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge
>> deal :);
>> but in a larger project, consider that a 4x speedup would be 4 minutes to 1
>> minute, and that is a huge difference in time.
>>
> You are still failing to see past your usecase. As said before - if
> there's any need to improve things say so.
> Note that you simply cannot apply the 1000x speedup in any situation.
Yes, you can't just linearly apply any scaling factor. However, when you
build mesa on a machine with a decent number of threads (I think our build
machine for the CI system has 32 threads), autotools+make is slow as mud.
Also, there's very little you can do to speed up configure since it's a
pile of shell and perl that inherently runs single-threaded and is fairly
complex due to mesa's complicated dependencies.
>>> As the port is not 1:1 wrt the autoconf one, the performance numbers
>>> above are comparing apples to oranges.
>>
>> I fail to see what I'm missing from meson that would have an effect on the
>> times I reported. There are some files that are installed by autoconf that I
>> didn't bother to install with meson (because I don't expect this to land).
>> Since
>> I didn't time installs, I don't see how it isn't an apples to apples
>> comparison.
>>
> You already (explicitly) mentioned some differences. Admittedly not a
> deal breaker.
>
>> I understand that libdrm is a pessimal case for recursive-make since most
>> sub folders contain < 5 C files, However, even if you were to flatten the make
>> files meson+ninja would still be faster when you consider that meson
>> configures and builds faster than autotools configures.
>>
> That's correct. If is so concerned - they should slim down the configure.ac ;-)
There are real limits as to what you can do there.
>>> If you/others are unhappy with the build times of libdrm - poke me on
>>> IRC. I will give you some easy tips on how to improve those.
>>>
>>> You have some good python knowledge - I would kindly urge you to
>>> improve/rewrite the slow and/or hacky python scripts we have in mesa.
>>> This is a topic that was mentioned multiple times, and a part where
>>> everyone will be glad to see some progress.
>>>
>>> Thanks
>>> Emil
>>
>> The real goal here is to do mesa (in case I didn't make that clear either), and
>> the advantage for mesa is not just performance, it's that meson supports visual
>> studio on windows; which means that we could hopefully not just get faster
>> builds, but also replace both autotools and scons with a single build system.
>>
> Yes that was more than clear. Yet it won't fly, I'm afraid.
>
> The VMWare people like their SCons,
How much? I would really rather the VMWare people speak on behalf of
VMWare. Meson is the single best shot we've ever had for replacing both
with one build system. I'm sure the VMware people would like to have a
build system that gets maintained by the community as a whole.
> and Meson is not a thing on neither BSD(s), Solaris (and derivatives) nor
> Android :-\
I have trouble bringing myself to care. The BSDs need to stop using 10
year old compilers. It can be made to work on Solaris and BSD if someone
bothered to put a little work into it. Besides, given that large chunks of
GNOME are switching they're going to have to make it work some day soon anyway.
Android is a bit unfortunate. Mesa is one of the few projects that let's
the Android people carry their build system in-tree and I would like to
keep that going if it were practical. Dylan and I have talked about this a
decent bit and one potential solution is to see if the meson people would
accept an Android back-end. Then we would be down to a single build system
(wouldn't that be nice).
> If there's something "slow" say what/where and we can improve upon
> things. You seems to be rewriting $world because someone sold you that
> A is the holy grail.
I don't think that's fair. No, Meson is not the holy grail but it is the
closest anyone has yet been able to come to a viable autotools replacement.
Speed is only one aspect to this. Unifying the Linux and windows builds is
also a significant advantage. Also, autotools is objectively terrible and
having a build system that's modifiable be mere humans without the need for
hours of pouring over documentation only to find that you did it wrong
anyway is a definite plus.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-17 2:03 ` Jason Ekstrand
@ 2017-03-17 2:28 ` Brian Paul
2017-03-22 17:59 ` Jose Fonseca
2017-03-17 4:12 ` Dylan Baker
2017-03-20 13:55 ` [Mesa-dev] " Emil Velikov
2 siblings, 1 reply; 94+ messages in thread
From: Brian Paul @ 2017-03-17 2:28 UTC (permalink / raw)
To: Jason Ekstrand; +Cc: ML mesa-dev, Emil Velikov, ML dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 5890 bytes --]
On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand <jason@jlekstrand.net>
wrote:
> On March 16, 2017 5:41:24 PM Emil Velikov <emil.l.velikov@gmail.com>
> wrote:
>
>> On 17 March 2017 at 00:21, Dylan Baker <dylan@pnwbakers.com> wrote:
>>
>>> Hi Emil,
>>>
>>> Quoting Emil Velikov (2017-03-16 16:35:33)
>>>
>>>> While I can see you're impressed by Meson, I would kindly urge you to
>>>> not use it here. As you look closely you can see that one could
>>>> trivially improve the times, yet the biggest thing is that most of the
>>>> code in libdrm must go ;-)
>>>>
>>>
>>> Perhaps I wasn't clear enough, I don't really expect this to land ever.
>>> I sent
>>> it out more because I'd written it and it works and is a useful
>>> demonstration of
>>> meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge
>>> deal :);
>>> but in a larger project, consider that a 4x speedup would be 4 minutes
>>> to 1
>>> minute, and that is a huge difference in time.
>>>
>>> You are still failing to see past your usecase. As said before - if
>> there's any need to improve things say so.
>> Note that you simply cannot apply the 1000x speedup in any situation.
>>
>
> Yes, you can't just linearly apply any scaling factor. However, when you
> build mesa on a machine with a decent number of threads (I think our build
> machine for the CI system has 32 threads), autotools+make is slow as mud.
> Also, there's very little you can do to speed up configure since it's a
> pile of shell and perl that inherently runs single-threaded and is fairly
> complex due to mesa's complicated dependencies.
>
> As the port is not 1:1 wrt the autoconf one, the performance numbers
>>>> above are comparing apples to oranges.
>>>>
>>>
>>> I fail to see what I'm missing from meson that would have an effect on
>>> the
>>> times I reported. There are some files that are installed by autoconf
>>> that I
>>> didn't bother to install with meson (because I don't expect this to
>>> land). Since
>>> I didn't time installs, I don't see how it isn't an apples to apples
>>> comparison.
>>>
>>> You already (explicitly) mentioned some differences. Admittedly not a
>> deal breaker.
>>
>> I understand that libdrm is a pessimal case for recursive-make since most
>>> sub folders contain < 5 C files, However, even if you were to flatten
>>> the make
>>> files meson+ninja would still be faster when you consider that meson
>>> configures and builds faster than autotools configures.
>>>
>>> That's correct. If is so concerned - they should slim down the
>> configure.ac ;-)
>>
>
> There are real limits as to what you can do there.
>
> If you/others are unhappy with the build times of libdrm - poke me on
>>>> IRC. I will give you some easy tips on how to improve those.
>>>>
>>>> You have some good python knowledge - I would kindly urge you to
>>>> improve/rewrite the slow and/or hacky python scripts we have in mesa.
>>>> This is a topic that was mentioned multiple times, and a part where
>>>> everyone will be glad to see some progress.
>>>>
>>>> Thanks
>>>> Emil
>>>>
>>>
>>> The real goal here is to do mesa (in case I didn't make that clear
>>> either), and
>>> the advantage for mesa is not just performance, it's that meson supports
>>> visual
>>> studio on windows; which means that we could hopefully not just get
>>> faster
>>> builds, but also replace both autotools and scons with a single build
>>> system.
>>>
>>> Yes that was more than clear. Yet it won't fly, I'm afraid.
>>
>> The VMWare people like their SCons,
>>
>
> How much? I would really rather the VMWare people speak on behalf of
> VMWare. Meson is the single best shot we've ever had for replacing both
> with one build system. I'm sure the VMware people would like to have a
> build system that gets maintained by the community as a whole.
>
Sure, I'd like to see one build system instead of two. Meson supports
Windows so that's good. But the big issue is our automated build system.
Replacing SCons with Meson could be a big deal in that context. It would
at least involve pulling Meson into our toolchain and rewriting a bunch of
Python code to grok Meson. I'd have to go off and investigate that to even
see if it's a possibility. Maybe next week.
-Brian
>
> and Meson is not a thing on neither BSD(s), Solaris (and derivatives) nor
>> Android :-\
>>
>
> I have trouble bringing myself to care. The BSDs need to stop using 10
> year old compilers. It can be made to work on Solaris and BSD if someone
> bothered to put a little work into it. Besides, given that large chunks of
> GNOME are switching they're going to have to make it work some day soon
> anyway.
>
> Android is a bit unfortunate. Mesa is one of the few projects that let's
> the Android people carry their build system in-tree and I would like to
> keep that going if it were practical. Dylan and I have talked about this a
> decent bit and one potential solution is to see if the meson people would
> accept an Android back-end. Then we would be down to a single build system
> (wouldn't that be nice).
>
> If there's something "slow" say what/where and we can improve upon
>> things. You seems to be rewriting $world because someone sold you that
>> A is the holy grail.
>>
>
> I don't think that's fair. No, Meson is not the holy grail but it is the
> closest anyone has yet been able to come to a viable autotools replacement.
>
> Speed is only one aspect to this. Unifying the Linux and windows builds
> is also a significant advantage. Also, autotools is objectively terrible
> and having a build system that's modifiable be mere humans without the need
> for hours of pouring over documentation only to find that you did it wrong
> anyway is a definite plus.
>
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
[-- Attachment #1.2: Type: text/html, Size: 8381 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-17 2:03 ` Jason Ekstrand
2017-03-17 2:28 ` Brian Paul
@ 2017-03-17 4:12 ` Dylan Baker
2017-03-17 6:02 ` Jonathan Gray
2017-03-20 13:55 ` [Mesa-dev] " Emil Velikov
2 siblings, 1 reply; 94+ messages in thread
From: Dylan Baker @ 2017-03-17 4:12 UTC (permalink / raw)
To: Emil Velikov, Jason Ekstrand; +Cc: ML mesa-dev, ML dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 1000 bytes --]
quoting jason ekstrand (2017-03-16 19:03:15)
> on march 16, 2017 5:41:24 pm emil velikov <emil.l.velikov@gmail.com> wrote:
> > and meson is not a thing on neither bsd(s), solaris (and derivatives) nor
> > android :-\
>
> i have trouble bringing myself to care. the bsds need to stop using 10
> year old compilers. it can be made to work on solaris and bsd if someone
> bothered to put a little work into it. besides, given that large chunks of
> gnome are switching they're going to have to make it work some day soon anyway.
I decided to check the ports on my freebsd box, it has meson, in fact:
freebsd: https://svnweb.freebsd.org/ports/head/devel/meson/
netbsd: http://pkgsrc.se/wip/py-meson
openbsd: http://ports.su/devel/meson
The only OS I couldn't find a package for is openindiana (the clostest thing to
Solaris I could come up with), but there is ninja for Solaris, and meson itself
is pure python installable via pip, so even there it's not impossible.
Dylan
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljLYjUACgkQCJ4WlhQG
iO8tpAf/esR9N18iME03bx59D6jvEjZyV0Vb/psJSvRRXPh5jqJMrwhU0xv0UA+j
t6vUwOFD2aTlBayTid6ePKCZ8sbmKeLOpdULOryY/boIz2F1EPzsgryu86NcTNlY
Fgupf+/6B9orhcJxj+9SSpGifQjm7m156Ha7BKUFOJs8vbpb0T6cGMCVCPsaxaiJ
/nkx9+pGh9Z4W3MYMfqR1qMne3ALy5d8w0geKxso0gZQLrlDC3XIvrchm0s/wrrX
/bttwefDVC015QdgPsD7bgy6Mr/gBs+CUmudk/LPFCKY5HdwsaQw3o1zTBlk7ExF
c96t/9kxkYvy+ePr/4v4lmANsnGYfA==
=JRB9
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-17 1:53 ` Marek Olšák
@ 2017-03-17 4:15 ` Dylan Baker
2017-03-17 21:18 ` Marek Olšák
0 siblings, 1 reply; 94+ messages in thread
From: Dylan Baker @ 2017-03-17 4:15 UTC (permalink / raw)
To: Marek Olšák; +Cc: mesa-dev, dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 1713 bytes --]
Quoting Marek Olšák (2017-03-16 18:53:59)
> On Fri, Mar 17, 2017 at 12:11 AM, Dylan Baker <dylan@pnwbakers.com> wrote:
> > Quoting Marek Olšák (2017-03-16 15:36:26)
> >> Is there a way not to use ninja with meson, because ninja redirects
> >> all stderr output from gcc to stdout, which breaks many development
> >> environments that expect errors in stderr?
> >>
> >> I'm basically saying that if ninja can't keep gcc errors in stderr, I
> >> wouldn't like any project that I might be involved in to require ninja
> >> for building.
> >>
> >> Marek
> >
> > There is no way to use another backend on Linux, and meson will not support
> > Make. Ninja is a big part of the appeal here, since it is faster than make is.
> > Are there particular tools you know don't work with ninja? It seems like in the
> > 7+ years since ninja came out that someone would have fixed the tools, or that
> > some stream redirection could be used to fix the problem, "ninja 1>&2"?
>
> I actually read some thread about it and the conclusion seemed to be
> that ninja developers don't care. I have no other option than to
> believe that ninja was made for automated build bots, not for
> development.
>
> Some editors expect that errors and only errors go to stderr and all
> other garbage info goes to stdout. This is something I can't change.
>
> Marek
And I found this: https://groups.google.com/forum/#!topic/ninja-build/4syh2jzXWcI
Which leads me to believe that they would be responsive to a patch, the core
team just doesn't have a use for it. There is in fact a patch already written
(linked in that thread), that just needs someone to clean it up and propose it
for merge.
Dylan
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljLYu8ACgkQCJ4WlhQG
iO/x7gf/Rk1S/v21Y0OBcBL0+wT6Gvn/+a8ZgC2tXP+KcqvAekQCHAU0C2rjfQJv
P7fSt1VPyMFASdqoHO4FKA3qyoWK9tHorc8BQWoXJ2dGMcewtLHwrx5dfM8zjYbM
TlMM8D7eNm2YhVpNabslNI2QOYCvRRmG5JSSDUy2lVEZRkH/4YAZA61fg2Ukgu8F
V+TraiYhsaQPb27c2mrVmL3ifCKACO87DETVqfMd0T5zGAzf++i9lLFIuLPTYAvN
Ow96fuDn2DWByI9UVgeANUTtiBFIfmmYnJYOXcFyIeN646EeJp7veiokJFvTeH+D
48J58vN9Wwu1Z6qYre4R9/QwZYvFQw==
=HEEV
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-17 4:12 ` Dylan Baker
@ 2017-03-17 6:02 ` Jonathan Gray
0 siblings, 0 replies; 94+ messages in thread
From: Jonathan Gray @ 2017-03-17 6:02 UTC (permalink / raw)
To: Dylan Baker; +Cc: ML mesa-dev, Emil Velikov, ML dri-devel
On Thu, Mar 16, 2017 at 09:12:38PM -0700, Dylan Baker wrote:
> quoting jason ekstrand (2017-03-16 19:03:15)
> > on march 16, 2017 5:41:24 pm emil velikov <emil.l.velikov@gmail.com> wrote:
> > > and meson is not a thing on neither bsd(s), solaris (and derivatives) nor
> > > android :-\
> >
> > i have trouble bringing myself to care. the bsds need to stop using 10
> > year old compilers. it can be made to work on solaris and bsd if someone
> > bothered to put a little work into it. besides, given that large chunks of
> > gnome are switching they're going to have to make it work some day soon anyway.
>
> I decided to check the ports on my freebsd box, it has meson, in fact:
> freebsd: https://svnweb.freebsd.org/ports/head/devel/meson/
> netbsd: http://pkgsrc.se/wip/py-meson
> openbsd: http://ports.su/devel/meson
>
> The only OS I couldn't find a package for is openindiana (the clostest thing to
> Solaris I could come up with), but there is ninja for Solaris, and meson itself
> is pure python installable via pip, so even there it's not impossible.
>
> Dylan
OpenBSD has libdrm in the xenocara tree. If libdrm were to switch
build systems I'd have to maintain a different build system for it.
There are effectively three source trees in OpenBSD. src with kernel
posix utilities, toolchain etc. xenocara with xorg, Mesa, fonts.
ports with everything else. src is self contained, xenocara can
only take dependencies on src and other parts of xenocara.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-16 21:57 ` Dylan Baker
@ 2017-03-17 10:05 ` Neil Armstrong
0 siblings, 0 replies; 94+ messages in thread
From: Neil Armstrong @ 2017-03-17 10:05 UTC (permalink / raw)
To: dri-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 5151 bytes --]
On 03/16/2017 10:57 PM, Dylan Baker wrote:
> Quoting Ilia Mirkin (2017-03-16 14:32:09)
>> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
>>> Why bother, and why would we want this? │~
>>>
>>> First it's written in python, which means the potential developer base
>>> is massive. And it provides a recursive view for humans, but a
>>> non-recursive view for the system. This is the best of both worlds,
>>> humans can organize the build system in a way that makes sense, and the
>>> machine gets a non-recursive build system. It also uses ninja rather
>>> than make, and ninja is faster than make inherently. Meson is also a
>>> simpler syntax than autotools or cmake it's not Turing Complete by
>>> design nor does it expose python, again, by design. This allows meson
>>> itself to be reimplemented in a another language if python becomes a
>>> dead-end or a bottle-neck. It also makes it much easier to understand
>>> what the build system is doing.
>>>
>>> What's different about using meson?
>>>
>>> Well, apart from a faster builds and less magic in the build system? The
>>> configure flags are different, it uses -D<opt>=<value> more like cmake
>>> than the --enable or --with flags of autotools, although oddly it uses
>>> --prefix and friends when calling meson, but not with mesonconf, there's
>>> a bug opened on this. Meson also doesn't support in-tree builds at all;
>>> all builds are done out of tree. It also doesn't provide a "make dist"
>>> target, fortunately there's this awesome tool called git, and it
>>> provides a "git archive" command that does much the same thing. Did I
>>> mention it's fast?
>>>
>>> Here are the performance numbers I see on a 2 core 4 thread SKL, without
>>> initial configuration, and building out of tree (using zsh):
>>>
>>> For meson the command line is:
>>> time (meson build -Dmanpages=true && ninja -C build)
>>>
>>> For autotools the command line is:
>>> time (mdkir build && cd build && ../autotools && make -j5 -l4)<Paste>
>>
>> Probably mkdir...
>
> derp, yeah.
>
>>
>>>
>>> meson (cold ccache): 13.37s user 1.74s system 255% cpu 5.907 total
>>> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
>>> meson (hot ccache): 2.13s user 0.39s system 154% cpu 1.633 total
>>> autotools (hot ccache): 13.93s user 0.73s system 102% cpu 14.259 total
>>>
>>> That's ~4x faster for a cold build and ~10x faster for a hot build.
>>>
>>> For a make clean && make style build with a hot cache:
>>> meson: 4.64s user 0.33s system 334% cpu 1.486 total
>>> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>>>
>>> Why bother with libdrm?
>>>
>>> It's a simple build system, that could be completely (or mostly
>>> completely) be ported in a very short time, and could serve as a tech
>>> demo for the advantages of using meson to garner feedback for embarking
>>> on a larger project, like mesa (which is what I'm planning to work on
>>> next).
>>>
>>> tl;dr
>>>
>>> I wrote this as practice for porting Mesa, and figured I might as well
>>> send it out since I wrote it.
>>>
>>> It is very likely that neither of these large patches will show up on the
>>> mailing list, but this is available at my github:
>>> https://github.com/dcbaker/libdrm wip/meson
>>
>> I haven't looked at meson or your patches in detail, but autotools
>> supports 2 very important use-cases very well:
>>
>> 1. ./configure --help
>> 2. Cross-compilation with minimal requirement from the project being built
>>
>> Can you comment on how these are handled in meson?
>>
>> Cheers,
>>
>> -ilia
>
> 1. mesonconf <builddir> provides much the same thing. You can also read the
> meson_options.txt file, which is generally pretty short. I haven't added
> descriptions to the options in this patch.
>
> 2. you write a small ini style configuration file, something like:
> [binaries]
> c = '/usr/bin/aarch64-linux-gnu-gc'
> ar = '/usr/bin/aarch64-linux-gnu-gcc-ar'
> strip = '/usr/bin/aarch64-linux-gnu-strip'
> pkg-config = '/usr/bin/aarch64-linux-gnu-pkgconfig'
I'm sure meson is a good tool, but a simple :
./configure --target=arch64-linux-gnu
is wayyyy simpler...
And the only requirement is "sh" for autotools.
Neil
>
> Then you just configure with:
> meson build --cross-file cross_file.txt
>
> then just ninja like normal
>
> There's a more detailed walkthrough here:
> https://github.com/mesonbuild/meson/wiki/Cross-compilation
>
> I was able to cross compile the arm libraries for aarch64 using basically the
> above configuration (I had to write a wrapper script for pkg-config to set a
> couple of environment variables and install and archlinux aarach64 chroot,
> because arch), of course, I don't have access to any arm machines that I could
> test with.
>
> Dylan
>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-17 4:15 ` Dylan Baker
@ 2017-03-17 21:18 ` Marek Olšák
0 siblings, 0 replies; 94+ messages in thread
From: Marek Olšák @ 2017-03-17 21:18 UTC (permalink / raw)
To: Dylan Baker; +Cc: mesa-dev, dri-devel
On Fri, Mar 17, 2017 at 5:15 AM, Dylan Baker <dylan@pnwbakers.com> wrote:
> Quoting Marek Olšák (2017-03-16 18:53:59)
>> On Fri, Mar 17, 2017 at 12:11 AM, Dylan Baker <dylan@pnwbakers.com> wrote:
>> > Quoting Marek Olšák (2017-03-16 15:36:26)
>> >> Is there a way not to use ninja with meson, because ninja redirects
>> >> all stderr output from gcc to stdout, which breaks many development
>> >> environments that expect errors in stderr?
>> >>
>> >> I'm basically saying that if ninja can't keep gcc errors in stderr, I
>> >> wouldn't like any project that I might be involved in to require ninja
>> >> for building.
>> >>
>> >> Marek
>> >
>> > There is no way to use another backend on Linux, and meson will not support
>> > Make. Ninja is a big part of the appeal here, since it is faster than make is.
>> > Are there particular tools you know don't work with ninja? It seems like in the
>> > 7+ years since ninja came out that someone would have fixed the tools, or that
>> > some stream redirection could be used to fix the problem, "ninja 1>&2"?
>>
>> I actually read some thread about it and the conclusion seemed to be
>> that ninja developers don't care. I have no other option than to
>> believe that ninja was made for automated build bots, not for
>> development.
>>
>> Some editors expect that errors and only errors go to stderr and all
>> other garbage info goes to stdout. This is something I can't change.
>>
>> Marek
>
> And I found this: https://groups.google.com/forum/#!topic/ninja-build/4syh2jzXWcI
>
> Which leads me to believe that they would be responsive to a patch, the core
> team just doesn't have a use for it. There is in fact a patch already written
> (linked in that thread), that just needs someone to clean it up and propose it
> for merge.
Well, I guess I can use that. It's still not nice to force some people
to use out-of-tree builds of ninja.
Marek
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-17 2:03 ` Jason Ekstrand
2017-03-17 2:28 ` Brian Paul
2017-03-17 4:12 ` Dylan Baker
@ 2017-03-20 13:55 ` Emil Velikov
2017-03-20 18:30 ` Matt Turner
2017-03-20 19:29 ` Rob Clark
2 siblings, 2 replies; 94+ messages in thread
From: Emil Velikov @ 2017-03-20 13:55 UTC (permalink / raw)
To: Jason Ekstrand; +Cc: ML mesa-dev, ML dri-devel, Dylan Baker
Seems like we ended up all over the place, so let me try afresh.
Above all:
- Saying "I don't care" about your users is arrogant - let us _not_
do that, please ?
Even Linux distribution maintainers have responded that "upstream does
not care us", which is indicative that we should be more careful what
we say.
For the rest - we're dealing with two orthogonal issues here:
* Multiple build systems
I believe we'll all agree that I might be the person who's been in all
the build systems the most.
Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
- [currently] there is no viable solution for Android
- dropping the Autotools will lead to OpenBSD and NetBSD having to
write one from scratch, IIRC Solaris/FreeBSD and others are in similar
boat.
These projects have been getting closer to upstream and "forcing" the
extra obstacle is effectively giving them the middle finger.
* Slow build times
Before we jump into "the next cool thing", let us properly utilise
what we have at the moment.
- I've asked multiple times about numbers behind those "let's make
the build faster" patches, but never got any :-\
- I can improve things but would need access to a fancy XX core
system to do rudimentary benchmarks/checks and test patches.
Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-20 13:55 ` [Mesa-dev] " Emil Velikov
@ 2017-03-20 18:30 ` Matt Turner
2017-03-20 19:39 ` [Mesa-dev] " Emil Velikov
` (2 more replies)
2017-03-20 19:29 ` Rob Clark
1 sibling, 3 replies; 94+ messages in thread
From: Matt Turner @ 2017-03-20 18:30 UTC (permalink / raw)
To: Emil Velikov; +Cc: ML mesa-dev, ML dri-devel
On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> Seems like we ended up all over the place, so let me try afresh.
>
> Above all:
> - Saying "I don't care" about your users is arrogant - let us _not_
> do that, please ?
Let's be honest, the OpenBSD is subjecting itself to some pretty
arbitrary restrictions caused including Mesa in its core: 10+ year old
GCC, non-GNU Make, and now no Meson. I don't believe either FreeBSD or
NetBSD keep Mesa as part of the core operating system, and as such
don't suffer from these problems.
For better or worse, they have made their choices and they get to live
with them. We are not beholden to them.
> Even Linux distribution maintainers have responded that "upstream does
> not care us", which is indicative that we should be more careful what
> we say.
Citation needed.
> For the rest - we're dealing with two orthogonal issues here:
>
> * Multiple build systems
> I believe we'll all agree that I might be the person who's been in all
> the build systems the most.
> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
No one is advocating dropping all of the existing build systems yet.
This patch is an RFC for a smaller project to start the discussion about Mesa.
> - [currently] there is no viable solution for Android
Acknowledged. Dylan is going to see if this is something that can be
solved in upstream Meson.
> - dropping the Autotools will lead to OpenBSD and NetBSD having to
> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
> boat.
Solaris is a closed source operating system whose developers do not
contribute to the project. We do not need to base our decisions on
them.
Mesa is not subject to ridiculous requirements (like in the case of
OpenBSD) in FreeBSD and NetBSD. Mesa depends on gmake in FreeBSD's
ports, for instance.
So I don't think any of this is true.
> These projects have been getting closer to upstream and "forcing" the
> extra obstacle is effectively giving them the middle finger.
No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
> * Slow build times
> Before we jump into "the next cool thing", let us properly utilise
> what we have at the moment.
It cannot be properly utilized. There is a patch on the list *today*
that is attempting to workaround the *design* of libtool. It's an
issue that's existed... since libtool?
https://bugzilla.redhat.com/show_bug.cgi?id=58664
https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
> - I've asked multiple times about numbers behind those "let's make
> the build faster" patches, but never got any :-\
What patches? The patches in this thread? What is your question?
> - I can improve things but would need access to a fancy XX core
> system to do rudimentary benchmarks/checks and test patches.
Have you ever seen an autotools build system for a project as complex
as Mesa that is both non-recursive and comprehensible? I have not, and
I did a lot of searching. In my opinion, this is an intractable
problem.
... and with Meson it is tractable. And it doesn't use libtool. And it
can replace at least 2 and maybe all three of our build systems.
Those all seem extremely compelling to me, and I think I've done
enough work on Mesa's build system and on a downstream distribution to
have a valuable opinion on the matter.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-20 13:55 ` [Mesa-dev] " Emil Velikov
2017-03-20 18:30 ` Matt Turner
@ 2017-03-20 19:29 ` Rob Clark
1 sibling, 0 replies; 94+ messages in thread
From: Rob Clark @ 2017-03-20 19:29 UTC (permalink / raw)
To: Emil Velikov; +Cc: ML mesa-dev, ML dri-devel, Jason Ekstrand, Dylan Baker
On Mon, Mar 20, 2017 at 9:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> Seems like we ended up all over the place, so let me try afresh.
>
> Above all:
> - Saying "I don't care" about your users is arrogant - let us _not_
> do that, please ?
> Even Linux distribution maintainers have responded that "upstream does
> not care us", which is indicative that we should be more careful what
> we say.
>
> For the rest - we're dealing with two orthogonal issues here:
>
> * Multiple build systems
> I believe we'll all agree that I might be the person who's been in all
> the build systems the most.
> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
> - [currently] there is no viable solution for Android
> - dropping the Autotools will lead to OpenBSD and NetBSD having to
> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
> boat.
> These projects have been getting closer to upstream and "forcing" the
> extra obstacle is effectively giving them the middle finger.
my $0.02.. I like autotools mostly because I've dealt with it long
enough to know how to debug when things go wrong, and I dislike
learning new build systems.
That said, a lot of other big userspace projects[1] seem to be
adopting meson so I expect that "learning something new" argument will
fade out. And if vmwgfx crew comes to the conclusion that they could
replace scons with meson, that would be quite compelling. (Enough to
justify keeping autotools and meson side-by-side for some time.) And
if someone could figure out how to make meson work for android builds,
it would be a slam-dunk.
The existing mesa build is complex enough that I doubt it is something
that could be replaced in one fell swoop. And I'm not really a fan of
living with 12 build systems in the long run. So probably the best
approach is to try to replace scons with meson, and then see where it
goes from there.
[1] well, I know of gnome and gstreamer.. not sure if/when they will
drop autotools build
BR,
-R
> * Slow build times
> Before we jump into "the next cool thing", let us properly utilise
> what we have at the moment.
> - I've asked multiple times about numbers behind those "let's make
> the build faster" patches, but never got any :-\
> - I can improve things but would need access to a fancy XX core
> system to do rudimentary benchmarks/checks and test patches.
>
> Thanks
> Emil
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-20 18:30 ` Matt Turner
@ 2017-03-20 19:39 ` Emil Velikov
2017-03-20 21:28 ` Timothy Arceri
2017-03-21 15:57 ` [Mesa-dev] " Matt Turner
2017-03-21 5:10 ` Jonathan Gray
2017-03-24 16:58 ` randyf
2 siblings, 2 replies; 94+ messages in thread
From: Emil Velikov @ 2017-03-20 19:39 UTC (permalink / raw)
To: Matt Turner; +Cc: ML mesa-dev, ML dri-devel, Jason Ekstrand, Dylan Baker
On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> Seems like we ended up all over the place, so let me try afresh.
>>
>> Above all:
>> - Saying "I don't care" about your users is arrogant - let us _not_
>> do that, please ?
>
> Let's be honest, the OpenBSD is subjecting itself to some pretty
> arbitrary restrictions caused including Mesa in its core: 10+ year old
> GCC,
IIRC Brian was using old MinGW GCC, which was one of the blockers - it
wasn't OpenBSD to blame here ;-)
> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
> NetBSD keep Mesa as part of the core operating system, and as such
> don't suffer from these problems.
>
> For better or worse, they have made their choices and they get to live
> with them. We are not beholden to them.
>
Overall this hunk seems misplaced. I go agree that we should not cater
for all their needs. At the same time, intentionally, breaking things
while we all can coexist is very strange.
>> Even Linux distribution maintainers have responded that "upstream does
>> not care us", which is indicative that we should be more careful what
>> we say.
>
> Citation needed.
>
https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
couple of instances where I've been contacted in private.
>> For the rest - we're dealing with two orthogonal issues here:
>>
>> * Multiple build systems
>> I believe we'll all agree that I might be the person who's been in all
>> the build systems the most.
>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>
> No one is advocating dropping all of the existing build systems yet.
>
> This patch is an RFC for a smaller project to start the discussion about Mesa.
>
>> - [currently] there is no viable solution for Android
>
> Acknowledged. Dylan is going to see if this is something that can be
> solved in upstream Meson.
>
I would suggest checking with Android people as well, as Meson.
There's some plans on moving to yet another build system - Blueprint.
>> - dropping the Autotools will lead to OpenBSD and NetBSD having to
>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>> boat.
>
> Solaris is a closed source operating system whose developers do not
> contribute to the project. We do not need to base our decisions on
> them.
>
> Mesa is not subject to ridiculous requirements (like in the case of
> OpenBSD) in FreeBSD and NetBSD.
Again - not a requirement, but coexistence.
> Mesa depends on gmake in FreeBSD's
> ports, for instance.
>
That amongst others is a bug in their packaging.
> So I don't think any of this is true.
>
I'd suggest giving it a try then - grab a non-GNU make, a release
tarball and let me know if you spot any issues.
>> These projects have been getting closer to upstream and "forcing" the
>> extra obstacle is effectively giving them the middle finger.
>
> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>
Can we stop with the GCC thing ? Can we point to a place where we want
to use feature A introduced with GCC B and we don't ?
The anonymous unions/structs for example require newer GCC and we use
them extensively. If anything we have the workaround(s) for MSVC's
lack of designated initializers.
Not to mention that some/many of the restrictions are imposed by very
older enterprise linuxes.
>> * Slow build times
>> Before we jump into "the next cool thing", let us properly utilise
>> what we have at the moment.
>
> It cannot be properly utilized. There is a patch on the list *today*
> that is attempting to workaround the *design* of libtool. It's an
> issue that's existed... since libtool?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=58664
> https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
>
Yes design is ..., but I'm talking about utilising all the X cores on $platform.
>> - I've asked multiple times about numbers behind those "let's make
>> the build faster" patches, but never got any :-\
>
> What patches? The patches in this thread? What is your question?
>
Nearly every time we had a "let's remove this recursive Makefile"
patch I asked "what improvement are we talking about here - how long
does it take before/after this patch to build mesa".
I'm yet to see any numbers :-\
Some cases that come to mind - mapi (gles1/2), glsl, nir and the latest ANV.
>> - I can improve things but would need access to a fancy XX core
>> system to do rudimentary benchmarks/checks and test patches.
>
> Have you ever seen an autotools build system for a project as complex
> as Mesa that is both non-recursive and comprehensible? I have not, and
> I did a lot of searching. In my opinion, this is an intractable
> problem.
>
Haven't looked at all really - off the top of my head openvswitch comes to mind.
Then again, It's not as extensive as mesa :-\
> ... and with Meson it is tractable. And it doesn't use libtool. And it
> can replace at least 2 and maybe all three of our build systems.
>
> Those all seem extremely compelling to me, and I think I've done
> enough work on Mesa's build system and on a downstream distribution to
> have a valuable opinion on the matter.
Yes you did a lot of work on the autotools side, with less so on scons
and android.
What I'm saying is - let us be mature and stop it with the [reasonable
or not] hatred towards autotools.
It is far from perfect, yet we can improve things on our end rather
than throwing everything in the bin.
-Emil
P.S. Last I've looked Meson does not have a dist/distcheck target, not
sure about more exotic ones like cscope and friends.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-20 19:39 ` [Mesa-dev] " Emil Velikov
@ 2017-03-20 21:28 ` Timothy Arceri
2017-03-20 21:38 ` Jason Ekstrand
2017-03-21 5:00 ` Jonathan Gray
2017-03-21 15:57 ` [Mesa-dev] " Matt Turner
1 sibling, 2 replies; 94+ messages in thread
From: Timothy Arceri @ 2017-03-20 21:28 UTC (permalink / raw)
To: Emil Velikov, Matt Turner; +Cc: ML mesa-dev, ML dri-devel
On 21/03/17 06:39, Emil Velikov wrote:
> On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>> Seems like we ended up all over the place, so let me try afresh.
>>>
>>> Above all:
>>> - Saying "I don't care" about your users is arrogant - let us _not_
>>> do that, please ?
>>
>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>> GCC,
> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> wasn't OpenBSD to blame here ;-)
Sorry Emil I probably wasn't clear in our discussion. I sent out patches
to switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler.
I'd rather not go through the upgrade hassle if I don't have to."
Followed by Jose "We're internally building and shipping Mesa compiled
with GCC 4.4 (more specifically 4.4.3).
It's fine if you require GCC 4.8 on automake, but please leave support
for GCC 4.4.x in SCons."
By this point I got bored and moved on. But OpenBSDs GCC is a fork with
various features backported, from what I understand Mesa would not build
on a real GCC 4.2 release and we should not be using it as a min
version. IMO if OpenBSD want to maintain a GCC fork they can handle a
patch to downgrade the min GCC version.
I believe Jonathan would like us to stick with 4.2 as min but is
prepared to deal with it if we move on.
[1] https://patchwork.freedesktop.org/patch/109094/
>
>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>> NetBSD keep Mesa as part of the core operating system, and as such
>> don't suffer from these problems.
>>
>> For better or worse, they have made their choices and they get to live
>> with them. We are not beholden to them.
>>
> Overall this hunk seems misplaced. I go agree that we should not cater
> for all their needs. At the same time, intentionally, breaking things
> while we all can coexist is very strange.
>
>>> Even Linux distribution maintainers have responded that "upstream does
>>> not care us", which is indicative that we should be more careful what
>>> we say.
>>
>> Citation needed.
>>
> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
> couple of instances where I've been contacted in private.
>
>>> For the rest - we're dealing with two orthogonal issues here:
>>>
>>> * Multiple build systems
>>> I believe we'll all agree that I might be the person who's been in all
>>> the build systems the most.
>>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>
>> No one is advocating dropping all of the existing build systems yet.
>>
>> This patch is an RFC for a smaller project to start the discussion about Mesa.
>>
>>> - [currently] there is no viable solution for Android
>>
>> Acknowledged. Dylan is going to see if this is something that can be
>> solved in upstream Meson.
>>
> I would suggest checking with Android people as well, as Meson.
> There's some plans on moving to yet another build system - Blueprint.
>
>>> - dropping the Autotools will lead to OpenBSD and NetBSD having to
>>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>>> boat.
>>
>> Solaris is a closed source operating system whose developers do not
>> contribute to the project. We do not need to base our decisions on
>> them.
>>
>> Mesa is not subject to ridiculous requirements (like in the case of
>> OpenBSD) in FreeBSD and NetBSD.
> Again - not a requirement, but coexistence.
>
>> Mesa depends on gmake in FreeBSD's
>> ports, for instance.
>>
> That amongst others is a bug in their packaging.
>
>> So I don't think any of this is true.
>>
> I'd suggest giving it a try then - grab a non-GNU make, a release
> tarball and let me know if you spot any issues.
>
>>> These projects have been getting closer to upstream and "forcing" the
>>> extra obstacle is effectively giving them the middle finger.
>>
>> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>>
> Can we stop with the GCC thing ? Can we point to a place where we want
> to use feature A introduced with GCC B and we don't ?
I think you are missing the point, no-one wants to (should have to) look
up if features X was in GCC stone-age every-time they want to use
something. Also as I pointed out when discussing the Zlib min version,
we should be recommending min versions that are actually regularly
tested with Mesa. Frankenstein RHEL 6 and OpenBSD libs and tools with
significant backports should be left to the distros to sort out and do
their own qa testing/lowering of min versions recommended by Mesa.
>
> The anonymous unions/structs for example require newer GCC and we use
> them extensively. If anything we have the workaround(s) for MSVC's
> lack of designated initializers.
> Not to mention that some/many of the restrictions are imposed by very
> older enterprise linuxes.
??? I don't think we do. RHEL 6 is the oldest distro that actually ships
new version of Mesa and if that were the only concern we could have
bumped to GCC 4.8 already.
>
>>> * Slow build times
>>> Before we jump into "the next cool thing", let us properly utilise
>>> what we have at the moment.
>>
>> It cannot be properly utilized. There is a patch on the list *today*
>> that is attempting to workaround the *design* of libtool. It's an
>> issue that's existed... since libtool?
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=58664
>> https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
>>
> Yes design is ..., but I'm talking about utilising all the X cores on $platform.
>
>>> - I've asked multiple times about numbers behind those "let's make
>>> the build faster" patches, but never got any :-\
>>
>> What patches? The patches in this thread? What is your question?
>>
> Nearly every time we had a "let's remove this recursive Makefile"
> patch I asked "what improvement are we talking about here - how long
> does it take before/after this patch to build mesa".
> I'm yet to see any numbers :-\
>
> Some cases that come to mind - mapi (gles1/2), glsl, nir and the latest ANV.
>
>>> - I can improve things but would need access to a fancy XX core
>>> system to do rudimentary benchmarks/checks and test patches.
>>
>> Have you ever seen an autotools build system for a project as complex
>> as Mesa that is both non-recursive and comprehensible? I have not, and
>> I did a lot of searching. In my opinion, this is an intractable
>> problem.
>>
> Haven't looked at all really - off the top of my head openvswitch comes to mind.
> Then again, It's not as extensive as mesa :-\
>
>> ... and with Meson it is tractable. And it doesn't use libtool. And it
>> can replace at least 2 and maybe all three of our build systems.
>>
>> Those all seem extremely compelling to me, and I think I've done
>> enough work on Mesa's build system and on a downstream distribution to
>> have a valuable opinion on the matter.
> Yes you did a lot of work on the autotools side, with less so on scons
> and android.
>
> What I'm saying is - let us be mature and stop it with the [reasonable
> or not] hatred towards autotools.
> It is far from perfect, yet we can improve things on our end rather
> than throwing everything in the bin.
>
> -Emil
> P.S. Last I've looked Meson does not have a dist/distcheck target, not
> sure about more exotic ones like cscope and friends.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-20 21:28 ` Timothy Arceri
@ 2017-03-20 21:38 ` Jason Ekstrand
2017-03-21 5:00 ` Jonathan Gray
1 sibling, 0 replies; 94+ messages in thread
From: Jason Ekstrand @ 2017-03-20 21:38 UTC (permalink / raw)
To: Timothy Arceri; +Cc: ML mesa-dev, Emil Velikov, ML dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 8972 bytes --]
On Mon, Mar 20, 2017 at 2:28 PM, Timothy Arceri <tarceri@itsqueeze.com>
wrote:
>
>
> On 21/03/17 06:39, Emil Velikov wrote:
>
>> On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
>>
>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com>
>>> wrote:
>>>
>>>> Seems like we ended up all over the place, so let me try afresh.
>>>>
>>>> Above all:
>>>> - Saying "I don't care" about your users is arrogant - let us _not_
>>>> do that, please ?
>>>>
>>>
>>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>>> GCC,
>>>
>> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> wasn't OpenBSD to blame here ;-)
>>
>
> Sorry Emil I probably wasn't clear in our discussion. I sent out patches
> to switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
>
> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
> rather not go through the upgrade hassle if I don't have to."
>
> Followed by Jose "We're internally building and shipping Mesa compiled
> with GCC 4.4 (more specifically 4.4.3).
>
> It's fine if you require GCC 4.8 on automake, but please leave support
> for GCC 4.4.x in SCons."
>
> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
> various features backported, from what I understand Mesa would not build on
> a real GCC 4.2 release and we should not be using it as a min version. IMO
> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
> the min GCC version.
>
> I believe Jonathan would like us to stick with 4.2 as min but is prepared
> to deal with it if we move on.
>
> [1] https://patchwork.freedesktop.org/patch/109094/
>
>
>
>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>>> NetBSD keep Mesa as part of the core operating system, and as such
>>> don't suffer from these problems.
>>>
>>> For better or worse, they have made their choices and they get to live
>>> with them. We are not beholden to them.
>>>
>>> Overall this hunk seems misplaced. I go agree that we should not cater
>> for all their needs. At the same time, intentionally, breaking things
>> while we all can coexist is very strange.
>>
>
We're not trying to "break things". The objective is to substantially
simplify maintenance of our already very large and sprawling project. If
the best way to do that ends up breaking something ancient, that's
something we need to evaluate. However, "we're breaking X usecase" is not
a slam-dunk argument against it either.
> Even Linux distribution maintainers have responded that "upstream does
>>>> not care us", which is indicative that we should be more careful what
>>>> we say.
>>>>
>>>
>>> Citation needed.
>>>
>>> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>> couple of instances where I've been contacted in private.
>>
>> For the rest - we're dealing with two orthogonal issues here:
>>>>
>>>> * Multiple build systems
>>>> I believe we'll all agree that I might be the person who's been in all
>>>> the build systems the most.
>>>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>>>
>>>
>>> No one is advocating dropping all of the existing build systems yet.
>>>
>>> This patch is an RFC for a smaller project to start the discussion about
>>> Mesa.
>>>
>>> - [currently] there is no viable solution for Android
>>>>
>>>
>>> Acknowledged. Dylan is going to see if this is something that can be
>>> solved in upstream Meson.
>>>
>>> I would suggest checking with Android people as well, as Meson.
>> There's some plans on moving to yet another build system - Blueprint.
>>
>> - dropping the Autotools will lead to OpenBSD and NetBSD having to
>>>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>>>> boat.
>>>>
>>>
>>> Solaris is a closed source operating system whose developers do not
>>> contribute to the project. We do not need to base our decisions on
>>> them.
>>>
>>> Mesa is not subject to ridiculous requirements (like in the case of
>>> OpenBSD) in FreeBSD and NetBSD.
>>>
>> Again - not a requirement, but coexistence.
>>
>> Mesa depends on gmake in FreeBSD's
>>> ports, for instance.
>>>
>>> That amongst others is a bug in their packaging.
>>
>
As is not having clang available when they build mesa. But we still take
patches to keep it building on 4.2.
> So I don't think any of this is true.
>>>
>>> I'd suggest giving it a try then - grab a non-GNU make, a release
>> tarball and let me know if you spot any issues.
>>
>> These projects have been getting closer to upstream and "forcing" the
>>>> extra obstacle is effectively giving them the middle finger.
>>>>
>>>
>>> No. Requiring us to compile with a 10 year old GCC is giving a middle
>>> finger.
>>>
>>> Can we stop with the GCC thing ? Can we point to a place where we want
>> to use feature A introduced with GCC B and we don't ?
>>
>
Yes. I pushed a patch just this last week to not use a compound
initializer in a particular place because GCC 4.6 doesn't know that a
compound initializer made entirely out of constant literals is a constant
value. It works fine on moderately recent GCC but not on really old
versions. If I could use compound initializers when declaring static
constant things, it would make certain corners a bit nicer.
I could come up with more examples. That's just the freshest.
> I think you are missing the point, no-one wants to (should have to) look
> up if features X was in GCC stone-age every-time they want to use
> something. Also as I pointed out when discussing the Zlib min version, we
> should be recommending min versions that are actually regularly tested with
> Mesa. Frankenstein RHEL 6 and OpenBSD libs and tools with significant
> backports should be left to the distros to sort out and do their own qa
> testing/lowering of min versions recommended by Mesa.
>
>
>> The anonymous unions/structs for example require newer GCC and we use
>> them extensively. If anything we have the workaround(s) for MSVC's
>> lack of designated initializers.
>> Not to mention that some/many of the restrictions are imposed by very
>> older enterprise linuxes.
>>
>
> ??? I don't think we do. RHEL 6 is the oldest distro that actually ships
> new version of Mesa and if that were the only concern we could have bumped
> to GCC 4.8 already.
>
>
>> * Slow build times
>>>> Before we jump into "the next cool thing", let us properly utilise
>>>> what we have at the moment.
>>>>
>>>
>>> It cannot be properly utilized. There is a patch on the list *today*
>>> that is attempting to workaround the *design* of libtool. It's an
>>> issue that's existed... since libtool?
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=58664
>>> https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
>>>
>>> Yes design is ..., but I'm talking about utilising all the X cores on
>> $platform.
>>
>> - I've asked multiple times about numbers behind those "let's make
>>>> the build faster" patches, but never got any :-\
>>>>
>>>
>>> What patches? The patches in this thread? What is your question?
>>>
>>> Nearly every time we had a "let's remove this recursive Makefile"
>> patch I asked "what improvement are we talking about here - how long
>> does it take before/after this patch to build mesa".
>> I'm yet to see any numbers :-\
>>
>> Some cases that come to mind - mapi (gles1/2), glsl, nir and the latest
>> ANV.
>>
>> - I can improve things but would need access to a fancy XX core
>>>> system to do rudimentary benchmarks/checks and test patches.
>>>>
>>>
>>> Have you ever seen an autotools build system for a project as complex
>>> as Mesa that is both non-recursive and comprehensible? I have not, and
>>> I did a lot of searching. In my opinion, this is an intractable
>>> problem.
>>>
>>> Haven't looked at all really - off the top of my head openvswitch comes
>> to mind.
>> Then again, It's not as extensive as mesa :-\
>>
>> ... and with Meson it is tractable. And it doesn't use libtool. And it
>>> can replace at least 2 and maybe all three of our build systems.
>>>
>>> Those all seem extremely compelling to me, and I think I've done
>>> enough work on Mesa's build system and on a downstream distribution to
>>> have a valuable opinion on the matter.
>>>
>> Yes you did a lot of work on the autotools side, with less so on scons
>> and android.
>>
>> What I'm saying is - let us be mature and stop it with the [reasonable
>> or not] hatred towards autotools.
>> It is far from perfect, yet we can improve things on our end rather
>> than throwing everything in the bin.
>>
>
If we can make building our project faster and have a build system that's
way easier to maintain, why shouldn't we? Just because autotools is the
thing everyone's been using since forever doesn't make it good nor does it
mean it's the best choice for mesa. Let's actually evaluate our options.
[-- Attachment #1.2: Type: text/html, Size: 14311 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-20 21:28 ` Timothy Arceri
2017-03-20 21:38 ` Jason Ekstrand
@ 2017-03-21 5:00 ` Jonathan Gray
2017-03-21 16:00 ` Matt Turner
` (2 more replies)
1 sibling, 3 replies; 94+ messages in thread
From: Jonathan Gray @ 2017-03-21 5:00 UTC (permalink / raw)
To: Timothy Arceri; +Cc: ML mesa-dev, Emil Velikov, ML dri-devel
On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>
>
> On 21/03/17 06:39, Emil Velikov wrote:
> > On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > > > Seems like we ended up all over the place, so let me try afresh.
> > > >
> > > > Above all:
> > > > - Saying "I don't care" about your users is arrogant - let us _not_
> > > > do that, please ?
> > >
> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
> > > GCC,
> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> > wasn't OpenBSD to blame here ;-)
>
> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
>
> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
> rather not go through the upgrade hassle if I don't have to."
>
> Followed by Jose "We're internally building and shipping Mesa compiled with
> GCC 4.4 (more specifically 4.4.3).
>
> It's fine if you require GCC 4.8 on automake, but please leave support
> for GCC 4.4.x in SCons."
>
> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
> various features backported, from what I understand Mesa would not build on
> a real GCC 4.2 release and we should not be using it as a min version. IMO
> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
> the min GCC version.
>
> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
> deal with it if we move on.
I would like to see Mesa test features it uses in configure rather than
arbitary versions that are what a certain linux distribution ships with.
The zlib change for instance didn't reference any specific problems with
older versions or interfaces required from newer versions.
We have one platform using clang/lld now (arm64) and are likely to move
others in future where possible. libtool has to be patched and the Mesa
configure script regenerated to make this work or Mesa won't build due
to libtool.m4 looking for specific strings in ld -v produced by bfd
binutils or gold...
And yes if you change the configure script to check for a newer version
I'll revert it locally like I did with the zlib one.
As I get the impression no one cares about patches for older GCC I've
not being sending them to the list, ie
commit d3d340d6026e516cc405a2eb1d925a7a7a467480
Author: Jonathan Gray <jsg@jsg.id.au>
Date: Thu Mar 16 00:30:07 2017 +1100
i965: don't use designated array initialisation
Don't use a form of designated array initialisation that breaks gcc 4.2.1.
compiler/brw_vec4_gs_visitor.cpp:589: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:590: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:591: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:592: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:593: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:594: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:595: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:596: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:597: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:598: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:599: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:600: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:601: error: expected primary-expression before '[' token
compiler/brw_vec4_gs_visitor.cpp:602: error: expected primary-expression before '[' token
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
diff --git a/src/intel/compiler/brw_vec4_gs_visitor.cpp b/src/intel/compiler/brw_vec4_gs_visitor.cpp
index 4a8b5be30e..e7a502306e 100644
--- a/src/intel/compiler/brw_vec4_gs_visitor.cpp
+++ b/src/intel/compiler/brw_vec4_gs_visitor.cpp
@@ -585,23 +585,6 @@ vec4_gs_visitor::gs_end_primitive()
emit(OR(dst_reg(this->control_data_bits), this->control_data_bits, mask));
}
-static const GLuint gl_prim_to_hw_prim[GL_TRIANGLE_STRIP_ADJACENCY+1] = {
- [GL_POINTS] =_3DPRIM_POINTLIST,
- [GL_LINES] = _3DPRIM_LINELIST,
- [GL_LINE_LOOP] = _3DPRIM_LINELOOP,
- [GL_LINE_STRIP] = _3DPRIM_LINESTRIP,
- [GL_TRIANGLES] = _3DPRIM_TRILIST,
- [GL_TRIANGLE_STRIP] = _3DPRIM_TRISTRIP,
- [GL_TRIANGLE_FAN] = _3DPRIM_TRIFAN,
- [GL_QUADS] = _3DPRIM_QUADLIST,
- [GL_QUAD_STRIP] = _3DPRIM_QUADSTRIP,
- [GL_POLYGON] = _3DPRIM_POLYGON,
- [GL_LINES_ADJACENCY] = _3DPRIM_LINELIST_ADJ,
- [GL_LINE_STRIP_ADJACENCY] = _3DPRIM_LINESTRIP_ADJ,
- [GL_TRIANGLES_ADJACENCY] = _3DPRIM_TRILIST_ADJ,
- [GL_TRIANGLE_STRIP_ADJACENCY] = _3DPRIM_TRISTRIP_ADJ,
-};
-
extern "C" const unsigned *
brw_compile_gs(const struct brw_compiler *compiler, void *log_data,
void *mem_ctx,
@@ -814,9 +797,51 @@ brw_compile_gs(const struct brw_compiler *compiler, void *log_data,
else
prog_data->base.urb_entry_size = ALIGN(output_size_bytes, 128) / 128;
- assert(shader->info->gs.output_primitive < ARRAY_SIZE(gl_prim_to_hw_prim));
- prog_data->output_topology =
- gl_prim_to_hw_prim[shader->info->gs.output_primitive];
+ assert(shader->info->gs.output_primitive < (GL_TRIANGLE_STRIP_ADJACENCY+1));
+ switch (shader->info->gs.output_primitive) {
+ case GL_POINTS:
+ prog_data->output_topology =_3DPRIM_POINTLIST;
+ break;
+ case GL_LINES:
+ prog_data->output_topology = _3DPRIM_LINELIST;
+ break;
+ case GL_LINE_LOOP:
+ prog_data->output_topology = _3DPRIM_LINELOOP;
+ break;
+ case GL_LINE_STRIP:
+ prog_data->output_topology = _3DPRIM_LINESTRIP;
+ break;
+ case GL_TRIANGLES:
+ prog_data->output_topology = _3DPRIM_TRILIST;
+ break;
+ case GL_TRIANGLE_STRIP:
+ prog_data->output_topology = _3DPRIM_TRISTRIP;
+ break;
+ case GL_TRIANGLE_FAN:
+ prog_data->output_topology = _3DPRIM_TRIFAN;
+ break;
+ case GL_QUADS:
+ prog_data->output_topology = _3DPRIM_QUADLIST;
+ break;
+ case GL_QUAD_STRIP:
+ prog_data->output_topology = _3DPRIM_QUADSTRIP;
+ break;
+ case GL_POLYGON:
+ prog_data->output_topology = _3DPRIM_POLYGON;
+ break;
+ case GL_LINES_ADJACENCY:
+ prog_data->output_topology = _3DPRIM_LINELIST_ADJ;
+ break;
+ case GL_LINE_STRIP_ADJACENCY:
+ prog_data->output_topology = _3DPRIM_LINESTRIP_ADJ;
+ break;
+ case GL_TRIANGLES_ADJACENCY:
+ prog_data->output_topology = _3DPRIM_TRILIST_ADJ;
+ break;
+ case GL_TRIANGLE_STRIP_ADJACENCY:
+ prog_data->output_topology = _3DPRIM_TRISTRIP_ADJ;
+ break;
+ }
prog_data->vertices_in = shader->info->gs.vertices_in;
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-20 18:30 ` Matt Turner
2017-03-20 19:39 ` [Mesa-dev] " Emil Velikov
@ 2017-03-21 5:10 ` Jonathan Gray
2017-03-21 16:11 ` [Mesa-dev] " Matt Turner
2017-03-24 16:58 ` randyf
2 siblings, 1 reply; 94+ messages in thread
From: Jonathan Gray @ 2017-03-21 5:10 UTC (permalink / raw)
To: Matt Turner; +Cc: ML mesa-dev, Emil Velikov, ML dri-devel
On Mon, Mar 20, 2017 at 11:30:25AM -0700, Matt Turner wrote:
> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > Seems like we ended up all over the place, so let me try afresh.
> >
> > Above all:
> > - Saying "I don't care" about your users is arrogant - let us _not_
> > do that, please ?
>
> Let's be honest, the OpenBSD is subjecting itself to some pretty
> arbitrary restrictions caused including Mesa in its core: 10+ year old
> GCC, non-GNU Make, and now no Meson. I don't believe either FreeBSD or
> NetBSD keep Mesa as part of the core operating system, and as such
> don't suffer from these problems.
>
> For better or worse, they have made their choices and they get to live
> with them. We are not beholden to them.
This isn't a situation like OpenSSH where people explicitly go out of
their way to provide support for and test multiple systems and add
support for horrible things like PAM. It is more along the lines of
considering integrating patches sent by others to make code build.
>
> > Even Linux distribution maintainers have responded that "upstream does
> > not care us", which is indicative that we should be more careful what
> > we say.
>
> Citation needed.
>
> > For the rest - we're dealing with two orthogonal issues here:
> >
> > * Multiple build systems
> > I believe we'll all agree that I might be the person who's been in all
> > the build systems the most.
> > Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>
> No one is advocating dropping all of the existing build systems yet.
>
> This patch is an RFC for a smaller project to start the discussion about Mesa.
>
> > - [currently] there is no viable solution for Android
>
> Acknowledged. Dylan is going to see if this is something that can be
> solved in upstream Meson.
>
> > - dropping the Autotools will lead to OpenBSD and NetBSD having to
> > write one from scratch, IIRC Solaris/FreeBSD and others are in similar
> > boat.
>
> Solaris is a closed source operating system whose developers do not
> contribute to the project. We do not need to base our decisions on
> them.
So Mesa will remove support for libglvnd then? I don't see a lot of
open source non-Mesa alternatives for libGL.
Oh and the mingw, windows and macos support can go as well, great!
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-16 21:25 [RFC libdrm 0/2] Replace the build system with meson Dylan Baker
` (4 preceding siblings ...)
2017-03-16 23:35 ` Emil Velikov
@ 2017-03-21 14:44 ` Jani Nikula
2017-03-21 15:13 ` Grazvydas Ignotas
2017-03-21 16:22 ` Dylan Baker
2017-03-21 16:50 ` Kai Wasserbäch
2017-03-22 16:40 ` Alex Deucher
7 siblings, 2 replies; 94+ messages in thread
From: Jani Nikula @ 2017-03-21 14:44 UTC (permalink / raw)
To: Dylan Baker, dri-devel; +Cc: mesa-dev
On Thu, 16 Mar 2017, Dylan Baker <dylan@pnwbakers.com> wrote:
> First it's written in python, [...]
How does meson handle python 2 vs. 3? How do you avoid issues in the
build files wrt this? On Debian meson seems to depend on python 3, so
are they fully python 3?
How does meson handle build file backwards compatibility between meson
versions? I don't intend to flame, but I've found for some reason many
python projects don't seem to take this very seriously. Either having
conditionals in build files to support building with several meson
versions or always requiring the latest and greatest version would be
rather annoying.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 14:44 ` Jani Nikula
@ 2017-03-21 15:13 ` Grazvydas Ignotas
2017-03-21 15:15 ` Ilia Mirkin
2017-03-21 16:16 ` Dylan Baker
2017-03-21 16:22 ` Dylan Baker
1 sibling, 2 replies; 94+ messages in thread
From: Grazvydas Ignotas @ 2017-03-21 15:13 UTC (permalink / raw)
To: Jani Nikula; +Cc: mesa-dev, dri-devel, Dylan Baker
It might make sense to give more attention to cmake just because many
mesa-related projects are already using it: llvm, piglit, vulkan
loader and demos, mesa-demos, etc. Not sure how well it supports BSDs
and windows, but everyone building graphics stacks or contributing to
mesa should already be comfortable with cmake thanks to piglit and
llvm, which might not be the case for meson.
Gražvydas
On Tue, Mar 21, 2017 at 4:44 PM, Jani Nikula
<jani.nikula@linux.intel.com> wrote:
> On Thu, 16 Mar 2017, Dylan Baker <dylan@pnwbakers.com> wrote:
>> First it's written in python, [...]
>
> How does meson handle python 2 vs. 3? How do you avoid issues in the
> build files wrt this? On Debian meson seems to depend on python 3, so
> are they fully python 3?
>
> How does meson handle build file backwards compatibility between meson
> versions? I don't intend to flame, but I've found for some reason many
> python projects don't seem to take this very seriously. Either having
> conditionals in build files to support building with several meson
> versions or always requiring the latest and greatest version would be
> rather annoying.
>
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Technology Center
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 15:13 ` Grazvydas Ignotas
@ 2017-03-21 15:15 ` Ilia Mirkin
2017-03-21 16:16 ` Dylan Baker
1 sibling, 0 replies; 94+ messages in thread
From: Ilia Mirkin @ 2017-03-21 15:15 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: mesa-dev, dri-devel, Jani Nikula
On Tue, Mar 21, 2017 at 11:13 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> everyone building graphics stacks or contributing to
> mesa should already be comfortable with cmake thanks to piglit and
> llvm, which might not be the case for meson.
Or they could be contributing to mesa because it's the last project
with a sane build system.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-20 19:39 ` [Mesa-dev] " Emil Velikov
2017-03-20 21:28 ` Timothy Arceri
@ 2017-03-21 15:57 ` Matt Turner
2017-03-21 17:16 ` Emil Velikov
2017-03-24 20:44 ` [Mesa-dev] " Chad Versace
1 sibling, 2 replies; 94+ messages in thread
From: Matt Turner @ 2017-03-21 15:57 UTC (permalink / raw)
To: Emil Velikov; +Cc: ML mesa-dev, ML dri-devel, Jason Ekstrand, Dylan Baker
On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>> Seems like we ended up all over the place, so let me try afresh.
>>>
>>> Above all:
>>> - Saying "I don't care" about your users is arrogant - let us _not_
>>> do that, please ?
>>
>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>> GCC,
> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> wasn't OpenBSD to blame here ;-)
>
>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>> NetBSD keep Mesa as part of the core operating system, and as such
>> don't suffer from these problems.
>>
>> For better or worse, they have made their choices and they get to live
>> with them. We are not beholden to them.
>>
> Overall this hunk seems misplaced. I go agree that we should not cater
> for all their needs. At the same time, intentionally, breaking things
> while we all can coexist is very strange.
>
>>> Even Linux distribution maintainers have responded that "upstream does
>>> not care us", which is indicative that we should be more careful what
>>> we say.
>>
>> Citation needed.
>>
> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
> couple of instances where I've been contacted in private.
>
>>> For the rest - we're dealing with two orthogonal issues here:
>>>
>>> * Multiple build systems
>>> I believe we'll all agree that I might be the person who's been in all
>>> the build systems the most.
>>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>
>> No one is advocating dropping all of the existing build systems yet.
>>
>> This patch is an RFC for a smaller project to start the discussion about Mesa.
>>
>>> - [currently] there is no viable solution for Android
>>
>> Acknowledged. Dylan is going to see if this is something that can be
>> solved in upstream Meson.
>>
> I would suggest checking with Android people as well, as Meson.
> There's some plans on moving to yet another build system - Blueprint.
>
>>> - dropping the Autotools will lead to OpenBSD and NetBSD having to
>>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>>> boat.
>>
>> Solaris is a closed source operating system whose developers do not
>> contribute to the project. We do not need to base our decisions on
>> them.
>>
>> Mesa is not subject to ridiculous requirements (like in the case of
>> OpenBSD) in FreeBSD and NetBSD.
> Again - not a requirement, but coexistence.
>
>> Mesa depends on gmake in FreeBSD's
>> ports, for instance.
>>
> That amongst others is a bug in their packaging.
That is not even remotely the point.
My point is that they are not subjecting themselves (and us by
extension, since you want to let them) to such ridiculous
requirements.
>> So I don't think any of this is true.
>>
> I'd suggest giving it a try then - grab a non-GNU make, a release
> tarball and let me know if you spot any issues.
>
>>> These projects have been getting closer to upstream and "forcing" the
>>> extra obstacle is effectively giving them the middle finger.
>>
>> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>>
> Can we stop with the GCC thing ? Can we point to a place where we want
> to use feature A introduced with GCC B and we don't ?
Are you freaking serious?!
This happens *all* the time. It happened like two days ago with commit
28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
happened at least once in the previous month, and every month before
that.
> The anonymous unions/structs for example require newer GCC and we use
> them extensively. If anything we have the workaround(s) for MSVC's
> lack of designated initializers.
We actually have
if test "x$USE_GNU99" = xyes; then
CFLAGS="$CFLAGS -std=gnu99"
else
CFLAGS="$CFLAGS -std=c99"
fi
in configure.ac to work around gcc-4.4 incompatibilities.
> Not to mention that some/many of the restrictions are imposed by very
> older enterprise linuxes.
which eventually go out of support and those requirements disappear.
Unlike OpenBSD's insistence on using the last GPLv2 GCC.
>>> * Slow build times
>>> Before we jump into "the next cool thing", let us properly utilise
>>> what we have at the moment.
>>
>> It cannot be properly utilized. There is a patch on the list *today*
>> that is attempting to workaround the *design* of libtool. It's an
>> issue that's existed... since libtool?
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=58664
>> https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
>>
> Yes design is ..., but I'm talking about utilising all the X cores on $platform.
>
>>> - I've asked multiple times about numbers behind those "let's make
>>> the build faster" patches, but never got any :-\
>>
>> What patches? The patches in this thread? What is your question?
>>
> Nearly every time we had a "let's remove this recursive Makefile"
> patch I asked "what improvement are we talking about here - how long
> does it take before/after this patch to build mesa".
> I'm yet to see any numbers :-\
Because it's basically always small. The whole project needs to be
non-recursive, otherwise you get lots of little directories and stalls
(generating format_srgb comes to mind). All the work making things
non-recursive are opportunistic, and don't really address the
completely intractable nature of the problem: there are still 95
Makefile.ams.
> Some cases that come to mind - mapi (gles1/2), glsl, nir and the latest ANV.
>
>>> - I can improve things but would need access to a fancy XX core
>>> system to do rudimentary benchmarks/checks and test patches.
>>
>> Have you ever seen an autotools build system for a project as complex
>> as Mesa that is both non-recursive and comprehensible? I have not, and
>> I did a lot of searching. In my opinion, this is an intractable
>> problem.
>>
> Haven't looked at all really - off the top of my head openvswitch comes to mind.
> Then again, It's not as extensive as mesa :-\
Just looked -- you know what their last commit to Makefile.am is?
Makefile: Drop vestiges of support for non-GNU Make.
>> ... and with Meson it is tractable. And it doesn't use libtool. And it
>> can replace at least 2 and maybe all three of our build systems.
>>
>> Those all seem extremely compelling to me, and I think I've done
>> enough work on Mesa's build system and on a downstream distribution to
>> have a valuable opinion on the matter.
> Yes you did a lot of work on the autotools side, with less so on scons
> and android.
>
> What I'm saying is - let us be mature and stop it with the [reasonable
> or not] hatred towards autotools.
Troll bait.
> It is far from perfect, yet we can improve things on our end rather
> than throwing everything in the bin.
I have. Again, I think I have done enough of that that I have some
credibility on the matter.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 5:00 ` Jonathan Gray
@ 2017-03-21 16:00 ` Matt Turner
2017-03-23 12:23 ` Jonathan Gray
2017-03-23 18:31 ` Emil Velikov
2 siblings, 0 replies; 94+ messages in thread
From: Matt Turner @ 2017-03-21 16:00 UTC (permalink / raw)
To: Jonathan Gray; +Cc: ML mesa-dev, Timothy Arceri, Emil Velikov, ML dri-devel
On Mon, Mar 20, 2017 at 10:00 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> > > > Seems like we ended up all over the place, so let me try afresh.
>> > > >
>> > > > Above all:
>> > > > - Saying "I don't care" about your users is arrogant - let us _not_
>> > > > do that, please ?
>> > >
>> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
>> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
>> > > GCC,
>> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> > wasn't OpenBSD to blame here ;-)
>>
>> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
>> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
>>
>> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
>> rather not go through the upgrade hassle if I don't have to."
>>
>> Followed by Jose "We're internally building and shipping Mesa compiled with
>> GCC 4.4 (more specifically 4.4.3).
>>
>> It's fine if you require GCC 4.8 on automake, but please leave support
>> for GCC 4.4.x in SCons."
>>
>> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
>> various features backported, from what I understand Mesa would not build on
>> a real GCC 4.2 release and we should not be using it as a min version. IMO
>> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
>> the min GCC version.
>>
>> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
>> deal with it if we move on.
>
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.
How can we reasonably do that? In the context of the patch you inlined
-- what would make us believe designated initializers aren't available
in some version of GCC and we should test for it? They're just a C99
feature AFAIK.
And what would we do if we check and they're not available? Presumably
you're not advocating for #ifdef'ing and having two pieces of the same
code.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 5:10 ` Jonathan Gray
@ 2017-03-21 16:11 ` Matt Turner
0 siblings, 0 replies; 94+ messages in thread
From: Matt Turner @ 2017-03-21 16:11 UTC (permalink / raw)
To: Jonathan Gray; +Cc: ML mesa-dev, Emil Velikov, ML dri-devel
On Mon, Mar 20, 2017 at 10:10 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
> On Mon, Mar 20, 2017 at 11:30:25AM -0700, Matt Turner wrote:
>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> > Seems like we ended up all over the place, so let me try afresh.
>> >
>> > Above all:
>> > - Saying "I don't care" about your users is arrogant - let us _not_
>> > do that, please ?
>>
>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>> GCC, non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>> NetBSD keep Mesa as part of the core operating system, and as such
>> don't suffer from these problems.
>>
>> For better or worse, they have made their choices and they get to live
>> with them. We are not beholden to them.
>
> This isn't a situation like OpenSSH where people explicitly go out of
> their way to provide support for and test multiple systems and add
> support for horrible things like PAM. It is more along the lines of
> considering integrating patches sent by others to make code build.
I think we (and you) have been able to deal with compiler problems
reasonably well. I don't have a particular problem taking patches for
things like that. GCC is just an example of the problem.
My core point is that OpenBSD has made choices to build Mesa with
tools and versions no one else uses. If we want to add a new build
dependency not in OpenBSD's core, I don't think it's fair for
OpenBSD's choices prevent us from moving forward.
>> > Even Linux distribution maintainers have responded that "upstream does
>> > not care us", which is indicative that we should be more careful what
>> > we say.
>>
>> Citation needed.
>>
>> > For the rest - we're dealing with two orthogonal issues here:
>> >
>> > * Multiple build systems
>> > I believe we'll all agree that I might be the person who's been in all
>> > the build systems the most.
>> > Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>
>> No one is advocating dropping all of the existing build systems yet.
>>
>> This patch is an RFC for a smaller project to start the discussion about Mesa.
>>
>> > - [currently] there is no viable solution for Android
>>
>> Acknowledged. Dylan is going to see if this is something that can be
>> solved in upstream Meson.
>>
>> > - dropping the Autotools will lead to OpenBSD and NetBSD having to
>> > write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>> > boat.
>>
>> Solaris is a closed source operating system whose developers do not
>> contribute to the project. We do not need to base our decisions on
>> them.
>
> So Mesa will remove support for libglvnd then? I don't see a lot of
> open source non-Mesa alternatives for libGL.
Huh? libglvnd is free software.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 15:13 ` Grazvydas Ignotas
2017-03-21 15:15 ` Ilia Mirkin
@ 2017-03-21 16:16 ` Dylan Baker
1 sibling, 0 replies; 94+ messages in thread
From: Dylan Baker @ 2017-03-21 16:16 UTC (permalink / raw)
To: Grazvydas Ignotas, Jani Nikula; +Cc: mesa-dev, dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 1693 bytes --]
I would personally rather have scons and autotools than cmake. I've had the
misfortune of using all three, and cmake is not an improvement in my opinion.
Quoting Grazvydas Ignotas (2017-03-21 08:13:31)
> It might make sense to give more attention to cmake just because many
> mesa-related projects are already using it: llvm, piglit, vulkan
> loader and demos, mesa-demos, etc. Not sure how well it supports BSDs
> and windows, but everyone building graphics stacks or contributing to
> mesa should already be comfortable with cmake thanks to piglit and
> llvm, which might not be the case for meson.
>
> Gražvydas
>
> On Tue, Mar 21, 2017 at 4:44 PM, Jani Nikula
> <jani.nikula@linux.intel.com> wrote:
> > On Thu, 16 Mar 2017, Dylan Baker <dylan@pnwbakers.com> wrote:
> >> First it's written in python, [...]
> >
> > How does meson handle python 2 vs. 3? How do you avoid issues in the
> > build files wrt this? On Debian meson seems to depend on python 3, so
> > are they fully python 3?
> >
> > How does meson handle build file backwards compatibility between meson
> > versions? I don't intend to flame, but I've found for some reason many
> > python projects don't seem to take this very seriously. Either having
> > conditionals in build files to support building with several meson
> > versions or always requiring the latest and greatest version would be
> > rather annoying.
> >
> >
> > BR,
> > Jani.
> >
> > --
> > Jani Nikula, Intel Open Source Technology Center
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljRUcQACgkQCJ4WlhQG
iO8k0wf+JPrMDgpj6lCLC+GkzsCWYhMO4FKgOv1Pz+G6aXkibt4/kZ59iQD9O4Kt
rtk186PzHI7cLuR6/UHscRZ4PKDVcLLrAkSNGPi/fRmuASFqLIn4BV6eKLy1urZB
/b6hgzD7pHK8SeR67N3S9pEBebEwR5bzDowfeZI2TEXk1bZhfK2E3GSvRT4Iui9K
UxqsFcne24LDofrLF24KGz+DSr5I4nTj2hPLVkjUw2utP33WFL8bjmt+Ncy6KhiC
sOWRJULfjGcqcuAY6HCOGTyEfjfxNiKZSwG9VwMsdhLvgxYsXt1rDZiSEfbXz/2L
zWKrfT/PrKDqNn+LMTEjBfIQBT/Olg==
=G9JD
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 14:44 ` Jani Nikula
2017-03-21 15:13 ` Grazvydas Ignotas
@ 2017-03-21 16:22 ` Dylan Baker
2017-03-22 4:23 ` [Mesa-dev] " Jonathan Gray
2017-03-22 8:24 ` Jani Nikula
1 sibling, 2 replies; 94+ messages in thread
From: Dylan Baker @ 2017-03-21 16:22 UTC (permalink / raw)
To: Jani Nikula, dri-devel; +Cc: mesa-dev
[-- Attachment #1.1: Type: text/plain, Size: 1483 bytes --]
Quoting Jani Nikula (2017-03-21 07:44:55)
> On Thu, 16 Mar 2017, Dylan Baker <dylan@pnwbakers.com> wrote:
> > First it's written in python, [...]
>
> How does meson handle python 2 vs. 3? How do you avoid issues in the
> build files wrt this? On Debian meson seems to depend on python 3, so
> are they fully python 3?
Meson requires python 3.4+, and doesn't support python 2. Python 3.4 was
released in 2012. It's also worth nothing that a couple of us have been working
to get mesa's python scripts python3 compatible, so in the (hopefully) near
future python2 wouldn't be required.
> How does meson handle build file backwards compatibility between meson
> versions? I don't intend to flame, but I've found for some reason many
> python projects don't seem to take this very seriously. Either having
> conditionals in build files to support building with several meson
> versions or always requiring the latest and greatest version would be
> rather annoying.
Meson makes backwards compatible changes, and the version can be queried using
`meson.version()`, which works using meson's version comparison mechanism. I
would say this about meson, it's not a 'python project', it's 'a project written
in python', and they've taken great pains to not expose python in meson, and
reserve the right to reimplement in a different language if python becomes an
issue.
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Technology Center
Dylan
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljRU1oACgkQCJ4WlhQG
iO9FPQf/USjTd1t2FhaR5MdQaFhtPFzxVSfztpsVsD7UEcH/8Iqa3Rts4hlv+1Er
BXibE8vperd4xR5s/28REzbcBZiMoWTzdtymrUGTzRjZ9m7lzp06TKhaNC/4n6Rp
t2ehnOka9AgPWTOYsNUB7rpQhnbZw+anKJtXMO9pwPvxQ/KWTKjzXXE8G0Ddks5b
CfTGzuZs1raCRH953u6zm/SbJRtodIOinEJ/OEZ8xzODkwie9Zlv46IZqFeG9ffl
YCd8tRiq5jzt7CjumT1FAFrCwL8DdDfLo91sENqWTzrCxmAhR+8KwxduA8sV5OwQ
sLVTc/CyxmAWvOKNzvJHLlrgbaaxdA==
=RBJK
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-16 21:25 [RFC libdrm 0/2] Replace the build system with meson Dylan Baker
` (5 preceding siblings ...)
2017-03-21 14:44 ` Jani Nikula
@ 2017-03-21 16:50 ` Kai Wasserbäch
2017-03-21 17:34 ` Dylan Baker
2017-03-22 16:40 ` Alex Deucher
7 siblings, 1 reply; 94+ messages in thread
From: Kai Wasserbäch @ 2017-03-21 16:50 UTC (permalink / raw)
To: Dylan Baker, dri-devel; +Cc: mesa-dev
[-- Attachment #1.1.1: Type: text/plain, Size: 3191 bytes --]
Hey Dylan,
I've just a few points, since I'm not too enthused by the prospect of having to
deal with yet another build system with yet another slightly different syntax.
But ultimately this is only a "my 2 cents" e-mail, since others are way deeper
involved with Mesa and their opinion is what matters in the end. Anyway, here
goes nothing.
This might be a dumb question but isn't Meson (through wrap files) one of the
build systems that download crap from all over the internet silently? Ie. making
a packager's/distribution's life hell? There is
<https://github.com/mesonbuild/meson/wiki/Wrap-dependency-system-manual#toggling-between-distro-packages-and-embedded-source>
but that seems to imply a silent fallback to downloading stuff. I would rather
have a configure step that fails if a dependency is not met instead of building
something that can't be distributed. Or is there a magic "--distribution-build"
flag? If there isn't I would rather see a switch to CMake (as others have
pointed out in this thread: many projects in the vicinity of Mesa already use
CMake), but I get that there's a lot of hate for CMake (even though the Meson
syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
would be unlikely.
Dylan Baker wrote on 16.03.2017 22:25:
> Why bother, and why would we want this?
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently.
Well, CMake (and probably others), see
<https://cmake.org/cmake/help/latest/generator/Ninja.html>, can use/generate for
ninja too.
> Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
>
> What's different about using meson?
>
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D<opt>=<value> more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?
Nothing against git archive, but you then would need to maintain .gitattributes
in addition to the build system input files, correct? Right now the distribution
rules are just in the Makefile.in files, making them more visible and less
easily forgotten.
> [...]
Cheers,
Kai
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 15:57 ` [Mesa-dev] " Matt Turner
@ 2017-03-21 17:16 ` Emil Velikov
2017-03-21 18:06 ` Matt Turner
2017-03-24 20:44 ` [Mesa-dev] " Chad Versace
1 sibling, 1 reply; 94+ messages in thread
From: Emil Velikov @ 2017-03-21 17:16 UTC (permalink / raw)
To: Matt Turner; +Cc: ML mesa-dev, ML dri-devel
On 21 March 2017 at 15:57, Matt Turner <mattst88@gmail.com> wrote:
> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>> Seems like we ended up all over the place, so let me try afresh.
>>>>
>>>> Above all:
>>>> - Saying "I don't care" about your users is arrogant - let us _not_
>>>> do that, please ?
>>>
>>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>>> GCC,
>> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> wasn't OpenBSD to blame here ;-)
>>
>>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>>> NetBSD keep Mesa as part of the core operating system, and as such
>>> don't suffer from these problems.
>>>
>>> For better or worse, they have made their choices and they get to live
>>> with them. We are not beholden to them.
>>>
>> Overall this hunk seems misplaced. I go agree that we should not cater
>> for all their needs. At the same time, intentionally, breaking things
>> while we all can coexist is very strange.
>>
>>>> Even Linux distribution maintainers have responded that "upstream does
>>>> not care us", which is indicative that we should be more careful what
>>>> we say.
>>>
>>> Citation needed.
>>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>> couple of instances where I've been contacted in private.
>>
>>>> For the rest - we're dealing with two orthogonal issues here:
>>>>
>>>> * Multiple build systems
>>>> I believe we'll all agree that I might be the person who's been in all
>>>> the build systems the most.
>>>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>>
>>> No one is advocating dropping all of the existing build systems yet.
>>>
>>> This patch is an RFC for a smaller project to start the discussion about Mesa.
>>>
>>>> - [currently] there is no viable solution for Android
>>>
>>> Acknowledged. Dylan is going to see if this is something that can be
>>> solved in upstream Meson.
>>>
>> I would suggest checking with Android people as well, as Meson.
>> There's some plans on moving to yet another build system - Blueprint.
>>
>>>> - dropping the Autotools will lead to OpenBSD and NetBSD having to
>>>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>>>> boat.
>>>
>>> Solaris is a closed source operating system whose developers do not
>>> contribute to the project. We do not need to base our decisions on
>>> them.
>>>
>>> Mesa is not subject to ridiculous requirements (like in the case of
>>> OpenBSD) in FreeBSD and NetBSD.
>> Again - not a requirement, but coexistence.
>>
>>> Mesa depends on gmake in FreeBSD's
>>> ports, for instance.
>>>
>> That amongst others is a bug in their packaging.
>
> That is not even remotely the point.
>
> My point is that they are not subjecting themselves (and us by
> extension, since you want to let them) to such ridiculous
> requirements.
>
I will kindly ask you to keep these adjectives outside of what aims to
be (?) technical discussion.
And on your question - 50-100 lines worth of compatibility changes
across a 6.5kloc of build system is not that unreasonable, right ?
>>> So I don't think any of this is true.
>>>
>> I'd suggest giving it a try then - grab a non-GNU make, a release
>> tarball and let me know if you spot any issues.
>>
>>>> These projects have been getting closer to upstream and "forcing" the
>>>> extra obstacle is effectively giving them the middle finger.
>>>
>>> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>>>
>> Can we stop with the GCC thing ? Can we point to a place where we want
>> to use feature A introduced with GCC B and we don't ?
>
> Are you freaking serious?!
>
> This happens *all* the time. It happened like two days ago with commit
> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
> happened at least once in the previous month, and every month before
> that.
>
Considering none of the ANV code is built outside of Linux, why you
guys will restrict yourself is beyond me.
Nine requires GCC 4.6 and Clover GCC 4.7 for a long time.
>> The anonymous unions/structs for example require newer GCC and we use
>> them extensively. If anything we have the workaround(s) for MSVC's
>> lack of designated initializers.
>
> We actually have
>
> if test "x$USE_GNU99" = xyes; then
> CFLAGS="$CFLAGS -std=gnu99"
> else
> CFLAGS="$CFLAGS -std=c99"
> fi
>
> in configure.ac to work around gcc-4.4 incompatibilities.
>
5-10 lines of configure code is not that much of a burden, right ?
>> Not to mention that some/many of the restrictions are imposed by very
>> older enterprise linuxes.
>
> which eventually go out of support and those requirements disappear.
> Unlike OpenBSD's insistence on using the last GPLv2 GCC.
>
At which point we can reconsider, right - perhaps they have the
functionality backported, have moved to new version/another compiler
etc.
>>>> * Slow build times
>>>> Before we jump into "the next cool thing", let us properly utilise
>>>> what we have at the moment.
>>>
>>> It cannot be properly utilized. There is a patch on the list *today*
>>> that is attempting to workaround the *design* of libtool. It's an
>>> issue that's existed... since libtool?
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=58664
>>> https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
>>>
>> Yes design is ..., but I'm talking about utilising all the X cores on $platform.
>>
>>>> - I've asked multiple times about numbers behind those "let's make
>>>> the build faster" patches, but never got any :-\
>>>
>>> What patches? The patches in this thread? What is your question?
>>>
>> Nearly every time we had a "let's remove this recursive Makefile"
>> patch I asked "what improvement are we talking about here - how long
>> does it take before/after this patch to build mesa".
>> I'm yet to see any numbers :-\
>
> Because it's basically always small.
IIRC Jason, mentioned something similar to "loads" with the recent ANV
move - silly me cannot find the quote :-\
Found another one though (from the glsl/nir move to compiler/)
On 16 December 2015 at 20:24, Matt Turner <mattst88@gmail.com> wrote:
> On Wed, Dec 16, 2015 at 8:53 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > Can anyone confirm how much of a penalty are we talking about (single
> > vs separate makefiles) ?
>
> I'm not going to take the time to quantify it. Just do a clean build
> and watch as 7 of your 8 cores sit idle as format_srgb.c is generated
> or shared-glapi/libglapi.la is linked. (A dual-core system is not
> going to demonstrate this issue properly)
This is where I should have said - "I don't have a 8 core system, so I
cannot measure it", although on your end one could have let it compile
[say, during your lunch] and share with some numbers.
Your reply is quite provocative and even if I've had an full-retard
moment, I'm not sure that this is the way to reply.
> The whole project needs to be
> non-recursive, otherwise you get lots of little directories and stalls
> (generating format_srgb comes to mind). All the work making things
> non-recursive are opportunistic, and don't really address the
> completely intractable nature of the problem: there are still 95
> Makefile.ams.
>
Fully agree - those can be reworked, but I simply cannot measure any
difference on the systems I have access to.
Hence, cannot estimate the severity of the problem.
>> Some cases that come to mind - mapi (gles1/2), glsl, nir and the latest ANV.
>>
>>>> - I can improve things but would need access to a fancy XX core
>>>> system to do rudimentary benchmarks/checks and test patches.
>>>
>>> Have you ever seen an autotools build system for a project as complex
>>> as Mesa that is both non-recursive and comprehensible? I have not, and
>>> I did a lot of searching. In my opinion, this is an intractable
>>> problem.
>>>
>> Haven't looked at all really - off the top of my head openvswitch comes to mind.
>> Then again, It's not as extensive as mesa :-\
>
> Just looked -- you know what their last commit to Makefile.am is?
>
> Makefile: Drop vestiges of support for non-GNU Make.
>
That's their decision. I am pointing out that one can have a sane
project w/o recursive makefiles, yet perfectly readable.
>>> ... and with Meson it is tractable. And it doesn't use libtool. And it
>>> can replace at least 2 and maybe all three of our build systems.
>>>
>>> Those all seem extremely compelling to me, and I think I've done
>>> enough work on Mesa's build system and on a downstream distribution to
>>> have a valuable opinion on the matter.
>> Yes you did a lot of work on the autotools side, with less so on scons
>> and android.
>>
>> What I'm saying is - let us be mature and stop it with the [reasonable
>> or not] hatred towards autotools.
>
> Troll bait.
>
? You're saying that nobody is bashing on autotools/friends... ok.
>> It is far from perfect, yet we can improve things on our end rather
>> than throwing everything in the bin.
>
> I have. Again, I think I have done enough of that that I have some
> credibility on the matter.
Not trying to belittle any of your work, but this does not parse in
reply to my suggestion, sorry.
Overall your replies seem quite spontaneous/emotional. If I'm making
you upset - I do apologise.
I'm simply trying to get as much technical details, which I seems to
be tailing at.
-Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 16:50 ` Kai Wasserbäch
@ 2017-03-21 17:34 ` Dylan Baker
2017-03-21 18:36 ` [Mesa-dev] " Kai Wasserbäch
0 siblings, 1 reply; 94+ messages in thread
From: Dylan Baker @ 2017-03-21 17:34 UTC (permalink / raw)
To: Kai Wasserbäch, dri-devel; +Cc: mesa-dev
[-- Attachment #1.1: Type: text/plain, Size: 6028 bytes --]
Hi Kai,
Quoting Kai Wasserbäch (2017-03-21 09:50:52)
> Hey Dylan,
> I've just a few points, since I'm not too enthused by the prospect of having to
> deal with yet another build system with yet another slightly different syntax.
> But ultimately this is only a "my 2 cents" e-mail, since others are way deeper
> involved with Mesa and their opinion is what matters in the end. Anyway, here
> goes nothing.
>
> This might be a dumb question but isn't Meson (through wrap files) one of the
> build systems that download crap from all over the internet silently? Ie. making
> a packager's/distribution's life hell? There is
> <https://github.com/mesonbuild/meson/wiki/Wrap-dependency-system-manual#toggling-between-distro-packages-and-embedded-source>
> but that seems to imply a silent fallback to downloading stuff. I would rather
> have a configure step that fails if a dependency is not met instead of building
> something that can't be distributed. Or is there a magic "--distribution-build"
> flag? If there isn't I would rather see a switch to CMake (as others have
> pointed out in this thread: many projects in the vicinity of Mesa already use
> CMake), but I get that there's a lot of hate for CMake (even though the Meson
> syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
> would be unlikely.
I hadn't even noticed wrap before. Looking at it wraps they seem to be mainly
aimed at windows and osx, where bundling is the norm, and not Linux and the BSDs
where it's not. What I would expect if the windows guys wanted to use wrap is
that we would have something like this:
if host_machine.system() != 'windows'
dep_zlib = dependency('zlib', version : '>1.0.0')
else
subproj_zlib = subproject('zlib')
dep_zlib = subproj_zlib.get_variable('zlib_dep')
endif
Which would make the dependency a hard requirement for non-windows system (i.e.
the configure fails if zlib isn't found *except* on windows), and windows could
fall back to wraps.
I have no plans to implement wrap for mesa in the port I would do, and would NAK
any patches that used wrap on Linux or BSD. The windows devs can make their own
choice on how to handle dependencies (I have no idea what their development
environment looks like and don't want to make that choice for them). I agree
with you it's not the way that Linux or BSD works, we have competent package
management solutions without the need to automatically download sources.
As for cmake. I've written enough cmake in piglit to last me a lifetime, meson
and cmake are the difference between python and perl, there may be some
superficial similarities, but they are *not* the same. One of the things I'll
reiterate that impressed me the most about meson is that it's syntax is simple,
not Turring-complete, and opinionated.
In fact, piglit is the best reason not not use cmake I can come up with. There
is an (admittedly clever) hack to allow building tests for each of the API's
supported (GL, GLES1, and GLES2+). It does this by re-reunning the cmake for
each API, which means you can't put things in the tests directory that can only
be run once. Every time I try to make changes to the Cmake I spend about an hour
trying to figure out why some code I've implemented doesn't work, only to
remember that. Build systems aren't programming languages, they shouldn't be
interesting, they should be declarative; cmake is a full scripting language with
enough warts to make bash look cuddly.
>
> Dylan Baker wrote on 16.03.2017 22:25:
> > Why bother, and why would we want this?
> >
> > First it's written in python, which means the potential developer base
> > is massive. And it provides a recursive view for humans, but a
> > non-recursive view for the system. This is the best of both worlds,
> > humans can organize the build system in a way that makes sense, and the
> > machine gets a non-recursive build system. It also uses ninja rather
> > than make, and ninja is faster than make inherently.
>
> Well, CMake (and probably others), see
> <https://cmake.org/cmake/help/latest/generator/Ninja.html>, can use/generate for
> ninja too.
Sure, I think we've gone over this in the rather long thread, ninja is really
just a "nice to have" since it's faster than make. The real advantages are:
1) one build system for linux and windows (reducing from 3 to 2 build systems)
2) meson much simpler than autotools, scons, or (especially) cmake
3) recursive meson files, flat ninja file.
>
> > Meson is also a
> > simpler syntax than autotools or cmake it's not Turing Complete by
> > design nor does it expose python, again, by design. This allows meson
> > itself to be reimplemented in a another language if python becomes a
> > dead-end or a bottle-neck. It also makes it much easier to understand
> > what the build system is doing.
> >
> > What's different about using meson?
> >
> > Well, apart from a faster builds and less magic in the build system? The
> > configure flags are different, it uses -D<opt>=<value> more like cmake
> > than the --enable or --with flags of autotools, although oddly it uses
> > --prefix and friends when calling meson, but not with mesonconf, there's
> > a bug opened on this. Meson also doesn't support in-tree builds at all;
> > all builds are done out of tree. It also doesn't provide a "make dist"
> > target, fortunately there's this awesome tool called git, and it
> > provides a "git archive" command that does much the same thing. Did I
> > mention it's fast?
>
> Nothing against git archive, but you then would need to maintain .gitattributes
> in addition to the build system input files, correct? Right now the distribution
> rules are just in the Makefile.in files, making them more visible and less
> easily forgotten.
I've never had to use gitattributes for anything, are you thinking for setting
export-ignore and export-subst?
Dylan
>
> > [...]
>
> Cheers,
> Kai
>
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljRZA8ACgkQCJ4WlhQG
iO/bYAf/WNpPr2g/mdjq7dmEv3rzRfNST6HAFPlYWTN7+A4tnaiLZTeQ2qC2csYM
me73r52TTg4ufptgwo7ezC06zSzJTj47h2gT/Eifj8eOUtCKNkwS6JgISi0/duYJ
/QkCrJ0qtugZF3CZPVEcHHU8stVih4OVi2E7Tk4qVVHvl5y0WXj9IJI5Rm02waQw
7yZXmbZhsOwDikJudUxSeKhb2GmxfQQuS8SIVEdWuAlZyvDleUbckaDYToppbyjQ
nbnkXSxuRlNhdWsaFtAZ7c0uiIlwjah5Jvmto6QRG6K5B/oQIoZA+MoUygaMoHc/
9oouf0hvs8ayYjTrxgJD5/AGJe/jEQ==
=wuvu
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 17:16 ` Emil Velikov
@ 2017-03-21 18:06 ` Matt Turner
2017-03-21 18:56 ` [Mesa-dev] " Emil Velikov
2017-03-24 20:59 ` Chad Versace
0 siblings, 2 replies; 94+ messages in thread
From: Matt Turner @ 2017-03-21 18:06 UTC (permalink / raw)
To: Emil Velikov; +Cc: ML mesa-dev, ML dri-devel
On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> On 21 March 2017 at 15:57, Matt Turner <mattst88@gmail.com> wrote:
>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>> On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
>>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>>> Seems like we ended up all over the place, so let me try afresh.
>>>>>
>>>>> Above all:
>>>>> - Saying "I don't care" about your users is arrogant - let us _not_
>>>>> do that, please ?
>>>>
>>>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>>>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>>>> GCC,
>>> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>>> wasn't OpenBSD to blame here ;-)
>>>
>>>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>>>> NetBSD keep Mesa as part of the core operating system, and as such
>>>> don't suffer from these problems.
>>>>
>>>> For better or worse, they have made their choices and they get to live
>>>> with them. We are not beholden to them.
>>>>
>>> Overall this hunk seems misplaced. I go agree that we should not cater
>>> for all their needs. At the same time, intentionally, breaking things
>>> while we all can coexist is very strange.
>>>
>>>>> Even Linux distribution maintainers have responded that "upstream does
>>>>> not care us", which is indicative that we should be more careful what
>>>>> we say.
>>>>
>>>> Citation needed.
>>>>
>>> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>>> couple of instances where I've been contacted in private.
>>>
>>>>> For the rest - we're dealing with two orthogonal issues here:
>>>>>
>>>>> * Multiple build systems
>>>>> I believe we'll all agree that I might be the person who's been in all
>>>>> the build systems the most.
>>>>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>>>
>>>> No one is advocating dropping all of the existing build systems yet.
>>>>
>>>> This patch is an RFC for a smaller project to start the discussion about Mesa.
>>>>
>>>>> - [currently] there is no viable solution for Android
>>>>
>>>> Acknowledged. Dylan is going to see if this is something that can be
>>>> solved in upstream Meson.
>>>>
>>> I would suggest checking with Android people as well, as Meson.
>>> There's some plans on moving to yet another build system - Blueprint.
>>>
>>>>> - dropping the Autotools will lead to OpenBSD and NetBSD having to
>>>>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>>>>> boat.
>>>>
>>>> Solaris is a closed source operating system whose developers do not
>>>> contribute to the project. We do not need to base our decisions on
>>>> them.
>>>>
>>>> Mesa is not subject to ridiculous requirements (like in the case of
>>>> OpenBSD) in FreeBSD and NetBSD.
>>> Again - not a requirement, but coexistence.
>>>
>>>> Mesa depends on gmake in FreeBSD's
>>>> ports, for instance.
>>>>
>>> That amongst others is a bug in their packaging.
>>
>> That is not even remotely the point.
>>
>> My point is that they are not subjecting themselves (and us by
>> extension, since you want to let them) to such ridiculous
>> requirements.
>>
> I will kindly ask you to keep these adjectives outside of what aims to
> be (?) technical discussion.
Huh?
Didn't you call us arrogant in this very thread? Didn't you suggest
we're immature?
> And on your question - 50-100 lines worth of compatibility changes
> across a 6.5kloc of build system is not that unreasonable, right ?
You're still not understanding my point.
>>>> So I don't think any of this is true.
>>>>
>>> I'd suggest giving it a try then - grab a non-GNU make, a release
>>> tarball and let me know if you spot any issues.
>>>
>>>>> These projects have been getting closer to upstream and "forcing" the
>>>>> extra obstacle is effectively giving them the middle finger.
>>>>
>>>> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>>>>
>>> Can we stop with the GCC thing ? Can we point to a place where we want
>>> to use feature A introduced with GCC B and we don't ?
>>
>> Are you freaking serious?!
>>
>> This happens *all* the time. It happened like two days ago with commit
>> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
>> happened at least once in the previous month, and every month before
>> that.
>>
> Considering none of the ANV code is built outside of Linux, why you
> guys will restrict yourself is beyond me.
I think you're confused.
> Nine requires GCC 4.6 and Clover GCC 4.7 for a long time.
>
>>> The anonymous unions/structs for example require newer GCC and we use
>>> them extensively. If anything we have the workaround(s) for MSVC's
>>> lack of designated initializers.
>>
>> We actually have
>>
>> if test "x$USE_GNU99" = xyes; then
>> CFLAGS="$CFLAGS -std=gnu99"
>> else
>> CFLAGS="$CFLAGS -std=c99"
>> fi
>>
>> in configure.ac to work around gcc-4.4 incompatibilities.
>>
> 5-10 lines of configure code is not that much of a burden, right ?
You're missing the point again.
>>> Not to mention that some/many of the restrictions are imposed by very
>>> older enterprise linuxes.
>>
>> which eventually go out of support and those requirements disappear.
>> Unlike OpenBSD's insistence on using the last GPLv2 GCC.
>>
> At which point we can reconsider, right - perhaps they have the
> functionality backported, have moved to new version/another compiler
> etc.
You're missing the point again.
>>>>> * Slow build times
>>>>> Before we jump into "the next cool thing", let us properly utilise
>>>>> what we have at the moment.
>>>>
>>>> It cannot be properly utilized. There is a patch on the list *today*
>>>> that is attempting to workaround the *design* of libtool. It's an
>>>> issue that's existed... since libtool?
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=58664
>>>> https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
>>>>
>>> Yes design is ..., but I'm talking about utilising all the X cores on $platform.
>>>
>>>>> - I've asked multiple times about numbers behind those "let's make
>>>>> the build faster" patches, but never got any :-\
>>>>
>>>> What patches? The patches in this thread? What is your question?
>>>>
>>> Nearly every time we had a "let's remove this recursive Makefile"
>>> patch I asked "what improvement are we talking about here - how long
>>> does it take before/after this patch to build mesa".
>>> I'm yet to see any numbers :-\
>>
>> Because it's basically always small.
> IIRC Jason, mentioned something similar to "loads" with the recent ANV
> move - silly me cannot find the quote :-\
>
> Found another one though (from the glsl/nir move to compiler/)
>
> On 16 December 2015 at 20:24, Matt Turner <mattst88@gmail.com> wrote:
>> On Wed, Dec 16, 2015 at 8:53 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
>> > Can anyone confirm how much of a penalty are we talking about (single
>> > vs separate makefiles) ?
>>
>> I'm not going to take the time to quantify it. Just do a clean build
>> and watch as 7 of your 8 cores sit idle as format_srgb.c is generated
>> or shared-glapi/libglapi.la is linked. (A dual-core system is not
>> going to demonstrate this issue properly)
>
> This is where I should have said - "I don't have a 8 core system, so I
> cannot measure it", although on your end one could have let it compile
> [say, during your lunch] and share with some numbers.
> Your reply is quite provocative and even if I've had an full-retard
> moment, I'm not sure that this is the way to reply.
>
>> The whole project needs to be
>> non-recursive, otherwise you get lots of little directories and stalls
>> (generating format_srgb comes to mind). All the work making things
>> non-recursive are opportunistic, and don't really address the
>> completely intractable nature of the problem: there are still 95
>> Makefile.ams.
>>
> Fully agree - those can be reworked, but I simply cannot measure any
> difference on the systems I have access to.
> Hence, cannot estimate the severity of the problem.
>
>>> Some cases that come to mind - mapi (gles1/2), glsl, nir and the latest ANV.
>>>
>>>>> - I can improve things but would need access to a fancy XX core
>>>>> system to do rudimentary benchmarks/checks and test patches.
>>>>
>>>> Have you ever seen an autotools build system for a project as complex
>>>> as Mesa that is both non-recursive and comprehensible? I have not, and
>>>> I did a lot of searching. In my opinion, this is an intractable
>>>> problem.
>>>>
>>> Haven't looked at all really - off the top of my head openvswitch comes to mind.
>>> Then again, It's not as extensive as mesa :-\
>>
>> Just looked -- you know what their last commit to Makefile.am is?
>>
>> Makefile: Drop vestiges of support for non-GNU Make.
>>
> That's their decision. I am pointing out that one can have a sane
> project w/o recursive makefiles, yet perfectly readable.
>
>>>> ... and with Meson it is tractable. And it doesn't use libtool. And it
>>>> can replace at least 2 and maybe all three of our build systems.
>>>>
>>>> Those all seem extremely compelling to me, and I think I've done
>>>> enough work on Mesa's build system and on a downstream distribution to
>>>> have a valuable opinion on the matter.
>>> Yes you did a lot of work on the autotools side, with less so on scons
>>> and android.
>>>
>>> What I'm saying is - let us be mature and stop it with the [reasonable
>>> or not] hatred towards autotools.
>>
>> Troll bait.
>>
> ? You're saying that nobody is bashing on autotools/friends... ok.
They are not my favorite pieces of software and I think there are
sound technical arguments in favor of Meson in comparison to them,
which I and others have made repeatedly in this thread.
None of that is immature.
>>> It is far from perfect, yet we can improve things on our end rather
>>> than throwing everything in the bin.
>>
>> I have. Again, I think I have done enough of that that I have some
>> credibility on the matter.
>
> Not trying to belittle any of your work, but this does not parse in
> reply to my suggestion, sorry.
>
>
> Overall your replies seem quite spontaneous/emotional. If I'm making
> you upset - I do apologise.
> I'm simply trying to get as much technical details, which I seems to
> be tailing at.
Let me try one last time:
(1) Non-recursive automake is necessary for parallel build performance
(2) Non-recursive automake is intractably unmaintainable for
sufficiently large projects
(3) Mesa is a sufficiently large project
Therefore using automake will be either bad for parallel build
performance, unmaintainable, or both.
Meson aims to be a build system actually capable of replacing
autotools (IMO unlike cmake, scons, waf, et al.). It offers a much
cleaner domain specific language for writing the build rules, while
generating non-recursive ninja build files. It does not use libtool.
It supports Windows. It supports cross compilation.
And it has momentum: libepoxy already has a Meson build system. Others
in the X.Org community are experimenting with it for libinput, Wayland
and Weston, and the xserver.
All of that makes Meson very compelling.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 17:34 ` Dylan Baker
@ 2017-03-21 18:36 ` Kai Wasserbäch
2017-03-21 21:16 ` Dylan Baker
0 siblings, 1 reply; 94+ messages in thread
From: Kai Wasserbäch @ 2017-03-21 18:36 UTC (permalink / raw)
To: dri-devel, mesa-dev; +Cc: Dylan Baker
[-- Attachment #1.1.1: Type: text/plain, Size: 7680 bytes --]
Hey Dylan,
Dylan Baker wrote on 21.03.2017 18:34:
> Quoting Kai Wasserbäch (2017-03-21 09:50:52)
>> I've just a few points, since I'm not too enthused by the prospect of having to
>> deal with yet another build system with yet another slightly different syntax.
>> But ultimately this is only a "my 2 cents" e-mail, since others are way deeper
>> involved with Mesa and their opinion is what matters in the end. Anyway, here
>> goes nothing.
>>
>> This might be a dumb question but isn't Meson (through wrap files) one of the
>> build systems that download crap from all over the internet silently? Ie. making
>> a packager's/distribution's life hell? There is
>> <https://github.com/mesonbuild/meson/wiki/Wrap-dependency-system-manual#toggling-between-distro-packages-and-embedded-source>
>> but that seems to imply a silent fallback to downloading stuff. I would rather
>> have a configure step that fails if a dependency is not met instead of building
>> something that can't be distributed. Or is there a magic "--distribution-build"
>> flag? If there isn't I would rather see a switch to CMake (as others have
>> pointed out in this thread: many projects in the vicinity of Mesa already use
>> CMake), but I get that there's a lot of hate for CMake (even though the Meson
>> syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
>> would be unlikely.
>
> I hadn't even noticed wrap before. Looking at it wraps they seem to be mainly
> aimed at windows and osx, where bundling is the norm, and not Linux and the BSDs
> where it's not. What I would expect if the windows guys wanted to use wrap is
> that we would have something like this:
>
> if host_machine.system() != 'windows'
> dep_zlib = dependency('zlib', version : '>1.0.0')
> else
> subproj_zlib = subproject('zlib')
> dep_zlib = subproj_zlib.get_variable('zlib_dep')
> endif
>
> Which would make the dependency a hard requirement for non-windows system (i.e.
> the configure fails if zlib isn't found *except* on windows), and windows could
> fall back to wraps.
>
> I have no plans to implement wrap for mesa in the port I would do, and would NAK
> any patches that used wrap on Linux or BSD. The windows devs can make their own
> choice on how to handle dependencies (I have no idea what their development
> environment looks like and don't want to make that choice for them). I agree
> with you it's not the way that Linux or BSD works, we have competent package
> management solutions without the need to automatically download sources.
I hope the rest of the Mesa project would follow such a rule. Because if there's
something I absolutely hate about all those "new" build systems, then it's their
tendency to just download stuff and build/include that. This seems to have risen
with Node and now spread into Rust and other parts of the FLOSS eco-system.
> As for cmake. I've written enough cmake in piglit to last me a lifetime, meson
> and cmake are the difference between python and perl, there may be some
> superficial similarities, but they are *not* the same. One of the things I'll
> reiterate that impressed me the most about meson is that it's syntax is simple,
> not Turring-complete, and opinionated.
>
> In fact, piglit is the best reason not not use cmake I can come up with. There
> is an (admittedly clever) hack to allow building tests for each of the API's
> supported (GL, GLES1, and GLES2+). It does this by re-reunning the cmake for
> each API, which means you can't put things in the tests directory that can only
> be run once. Every time I try to make changes to the Cmake I spend about an hour
> trying to figure out why some code I've implemented doesn't work, only to
> remember that. Build systems aren't programming languages, they shouldn't be
> interesting, they should be declarative; cmake is a full scripting language with
> enough warts to make bash look cuddly.
Hm, I have written a lot of CMakeFiles.txt and so far I've always been rather
happy with them. Not sure what Piglit is doing though.
>> Dylan Baker wrote on 16.03.2017 22:25:
>>> Why bother, and why would we want this?
>>>
>>> First it's written in python, which means the potential developer base
>>> is massive. And it provides a recursive view for humans, but a
>>> non-recursive view for the system. This is the best of both worlds,
>>> humans can organize the build system in a way that makes sense, and the
>>> machine gets a non-recursive build system. It also uses ninja rather
>>> than make, and ninja is faster than make inherently.
>>
>> Well, CMake (and probably others), see
>> <https://cmake.org/cmake/help/latest/generator/Ninja.html>, can use/generate for
>> ninja too.
>
> Sure, I think we've gone over this in the rather long thread, ninja is really
> just a "nice to have" since it's faster than make. The real advantages are:
> 1) one build system for linux and windows (reducing from 3 to 2 build systems)
CMake or SCons would do the same AFAICS. Plus CMake seems to be used in the
Android eco-system already
(<https://developer.android.com/ndk/guides/cmake.html>), which might mean it
could be easier for the Android downstreams of Mesa? Not sure on that though.
> 2) meson much simpler than autotools, scons, or (especially) cmake
OTOH CMake gives you CTest/CDash
(<https://cmake.org/cmake/help/latest/manual/ctest.1.html>), CPack
(<https://cmake.org/cmake/help/latest/manual/cpack.1.html>), dependency
visualisation
(<https://cmake.org/cmake/help/latest/module/CMakeGraphVizOptions.html>) and
many other things for (basically) free. Maybe that warrants some complexity?
> 3) recursive meson files, flat ninja file.
IIRC you would also get the same with CMake if you target Ninja.
>>> Meson is also a
>>> simpler syntax than autotools or cmake it's not Turing Complete by
>>> design nor does it expose python, again, by design. This allows meson
>>> itself to be reimplemented in a another language if python becomes a
>>> dead-end or a bottle-neck. It also makes it much easier to understand
>>> what the build system is doing.
>>>
>>> What's different about using meson?
>>>
>>> Well, apart from a faster builds and less magic in the build system? The
>>> configure flags are different, it uses -D<opt>=<value> more like cmake
>>> than the --enable or --with flags of autotools, although oddly it uses
>>> --prefix and friends when calling meson, but not with mesonconf, there's
>>> a bug opened on this. Meson also doesn't support in-tree builds at all;
>>> all builds are done out of tree. It also doesn't provide a "make dist"
>>> target, fortunately there's this awesome tool called git, and it
>>> provides a "git archive" command that does much the same thing. Did I
>>> mention it's fast?
>>
>> Nothing against git archive, but you then would need to maintain .gitattributes
>> in addition to the build system input files, correct? Right now the distribution
>> rules are just in the Makefile.in files, making them more visible and less
>> easily forgotten.
>
> I've never had to use gitattributes for anything, are you thinking for setting
> export-ignore and export-subst?
Yep. AFAICT we have several files which aren't distributed if you do "make
dist". Those would need to be excluded from a tarball built with git archive as
well. AFAIK that's done through having .gitattributes files in the tree.
Anyway, I don't want to bikeshed here, so I'll be silent as long as any possible
future build system doesn't download stuff behind my back.
Thanks for your reply!
Cheers,
Kai
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 18:06 ` Matt Turner
@ 2017-03-21 18:56 ` Emil Velikov
2017-03-21 19:08 ` Jason Ekstrand
2017-03-21 19:10 ` [Mesa-dev] " Matt Turner
2017-03-24 20:59 ` Chad Versace
1 sibling, 2 replies; 94+ messages in thread
From: Emil Velikov @ 2017-03-21 18:56 UTC (permalink / raw)
To: Matt Turner; +Cc: ML mesa-dev, ML dri-devel, Jason Ekstrand, Dylan Baker
On 21 March 2017 at 18:06, Matt Turner <mattst88@gmail.com> wrote:
> On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> On 21 March 2017 at 15:57, Matt Turner <mattst88@gmail.com> wrote:
>>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>> On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
>>>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>>>> Seems like we ended up all over the place, so let me try afresh.
>>>>>>
>>>>>> Above all:
>>>>>> - Saying "I don't care" about your users is arrogant - let us _not_
>>>>>> do that, please ?
>>>>>
>>>>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>>>>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>>>>> GCC,
>>>> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>>>> wasn't OpenBSD to blame here ;-)
>>>>
>>>>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>>>>> NetBSD keep Mesa as part of the core operating system, and as such
>>>>> don't suffer from these problems.
>>>>>
>>>>> For better or worse, they have made their choices and they get to live
>>>>> with them. We are not beholden to them.
>>>>>
>>>> Overall this hunk seems misplaced. I go agree that we should not cater
>>>> for all their needs. At the same time, intentionally, breaking things
>>>> while we all can coexist is very strange.
>>>>
>>>>>> Even Linux distribution maintainers have responded that "upstream does
>>>>>> not care us", which is indicative that we should be more careful what
>>>>>> we say.
>>>>>
>>>>> Citation needed.
>>>>>
>>>> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>>>> couple of instances where I've been contacted in private.
>>>>
>>>>>> For the rest - we're dealing with two orthogonal issues here:
>>>>>>
>>>>>> * Multiple build systems
>>>>>> I believe we'll all agree that I might be the person who's been in all
>>>>>> the build systems the most.
>>>>>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>>>>
>>>>> No one is advocating dropping all of the existing build systems yet.
>>>>>
>>>>> This patch is an RFC for a smaller project to start the discussion about Mesa.
>>>>>
>>>>>> - [currently] there is no viable solution for Android
>>>>>
>>>>> Acknowledged. Dylan is going to see if this is something that can be
>>>>> solved in upstream Meson.
>>>>>
>>>> I would suggest checking with Android people as well, as Meson.
>>>> There's some plans on moving to yet another build system - Blueprint.
>>>>
>>>>>> - dropping the Autotools will lead to OpenBSD and NetBSD having to
>>>>>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>>>>>> boat.
>>>>>
>>>>> Solaris is a closed source operating system whose developers do not
>>>>> contribute to the project. We do not need to base our decisions on
>>>>> them.
>>>>>
>>>>> Mesa is not subject to ridiculous requirements (like in the case of
>>>>> OpenBSD) in FreeBSD and NetBSD.
>>>> Again - not a requirement, but coexistence.
>>>>
>>>>> Mesa depends on gmake in FreeBSD's
>>>>> ports, for instance.
>>>>>
>>>> That amongst others is a bug in their packaging.
>>>
>>> That is not even remotely the point.
>>>
>>> My point is that they are not subjecting themselves (and us by
>>> extension, since you want to let them) to such ridiculous
>>> requirements.
>>>
>> I will kindly ask you to keep these adjectives outside of what aims to
>> be (?) technical discussion.
>
> Huh?
>
> Didn't you call us arrogant in this very thread? Didn't you suggest
> we're immature?
>
Should I was unclear previously - I'm not trying to belittle, insult
or otherwise offend your/anyone's contribution or input.
I'm hoping to have a technical discussion, which does not have phrases
such as "slow as mud" "i don't care", "X is ridiculous" and friends.
>> And on your question - 50-100 lines worth of compatibility changes
>> across a 6.5kloc of build system is not that unreasonable, right ?
>
> You're still not understanding my point.
>
>>>>> So I don't think any of this is true.
>>>>>
>>>> I'd suggest giving it a try then - grab a non-GNU make, a release
>>>> tarball and let me know if you spot any issues.
>>>>
>>>>>> These projects have been getting closer to upstream and "forcing" the
>>>>>> extra obstacle is effectively giving them the middle finger.
>>>>>
>>>>> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>>>>>
>>>> Can we stop with the GCC thing ? Can we point to a place where we want
>>>> to use feature A introduced with GCC B and we don't ?
>>>
>>> Are you freaking serious?!
>>>
>>> This happens *all* the time. It happened like two days ago with commit
>>> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
>>> happened at least once in the previous month, and every month before
>>> that.
>>>
>> Considering none of the ANV code is built outside of Linux, why you
>> guys will restrict yourself is beyond me.
>
> I think you're confused.
>
Can you elaborate ?
You pointed out that we're restricting ourselves to old GCC version
due to OpenBSD. Yet the example given is not code that is build, or
expected to build soon on said platform.
Hence, If you guys want to use functionality from GCC 4.7 [which I
would encourage you to do] it would be better to add a 3 line
configure check - just like st/nine and st/clover already do.
>> Nine requires GCC 4.6 and Clover GCC 4.7 for a long time.
>>
>>>> The anonymous unions/structs for example require newer GCC and we use
>>>> them extensively. If anything we have the workaround(s) for MSVC's
>>>> lack of designated initializers.
>>>
>>> We actually have
>>>
>>> if test "x$USE_GNU99" = xyes; then
>>> CFLAGS="$CFLAGS -std=gnu99"
>>> else
>>> CFLAGS="$CFLAGS -std=c99"
>>> fi
>>>
>>> in configure.ac to work around gcc-4.4 incompatibilities.
>>>
>> 5-10 lines of configure code is not that much of a burden, right ?
>
> You're missing the point again.
>
>>>> Not to mention that some/many of the restrictions are imposed by very
>>>> older enterprise linuxes.
>>>
>>> which eventually go out of support and those requirements disappear.
>>> Unlike OpenBSD's insistence on using the last GPLv2 GCC.
>>>
>> At which point we can reconsider, right - perhaps they have the
>> functionality backported, have moved to new version/another compiler
>> etc.
>
> You're missing the point again.
>
Can you/anyone elaborate on this/other points that I'm missing ? Please ?
>>>>>> * Slow build times
>>>>>> Before we jump into "the next cool thing", let us properly utilise
>>>>>> what we have at the moment.
>>>>>
>>>>> It cannot be properly utilized. There is a patch on the list *today*
>>>>> that is attempting to workaround the *design* of libtool. It's an
>>>>> issue that's existed... since libtool?
>>>>>
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=58664
>>>>> https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
>>>>>
>>>> Yes design is ..., but I'm talking about utilising all the X cores on $platform.
>>>>
>>>>>> - I've asked multiple times about numbers behind those "let's make
>>>>>> the build faster" patches, but never got any :-\
>>>>>
>>>>> What patches? The patches in this thread? What is your question?
>>>>>
>>>> Nearly every time we had a "let's remove this recursive Makefile"
>>>> patch I asked "what improvement are we talking about here - how long
>>>> does it take before/after this patch to build mesa".
>>>> I'm yet to see any numbers :-\
>>>
>>> Because it's basically always small.
>> IIRC Jason, mentioned something similar to "loads" with the recent ANV
>> move - silly me cannot find the quote :-\
>>
>> Found another one though (from the glsl/nir move to compiler/)
>>
>> On 16 December 2015 at 20:24, Matt Turner <mattst88@gmail.com> wrote:
>>> On Wed, Dec 16, 2015 at 8:53 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>
>>> > Can anyone confirm how much of a penalty are we talking about (single
>>> > vs separate makefiles) ?
>>>
>>> I'm not going to take the time to quantify it. Just do a clean build
>>> and watch as 7 of your 8 cores sit idle as format_srgb.c is generated
>>> or shared-glapi/libglapi.la is linked. (A dual-core system is not
>>> going to demonstrate this issue properly)
>>
>> This is where I should have said - "I don't have a 8 core system, so I
>> cannot measure it", although on your end one could have let it compile
>> [say, during your lunch] and share with some numbers.
>> Your reply is quite provocative and even if I've had an full-retard
>> moment, I'm not sure that this is the way to reply.
>>
>>> The whole project needs to be
>>> non-recursive, otherwise you get lots of little directories and stalls
>>> (generating format_srgb comes to mind). All the work making things
>>> non-recursive are opportunistic, and don't really address the
>>> completely intractable nature of the problem: there are still 95
>>> Makefile.ams.
>>>
>> Fully agree - those can be reworked, but I simply cannot measure any
>> difference on the systems I have access to.
>> Hence, cannot estimate the severity of the problem.
>>
>>>> Some cases that come to mind - mapi (gles1/2), glsl, nir and the latest ANV.
>>>>
>>>>>> - I can improve things but would need access to a fancy XX core
>>>>>> system to do rudimentary benchmarks/checks and test patches.
>>>>>
>>>>> Have you ever seen an autotools build system for a project as complex
>>>>> as Mesa that is both non-recursive and comprehensible? I have not, and
>>>>> I did a lot of searching. In my opinion, this is an intractable
>>>>> problem.
>>>>>
>>>> Haven't looked at all really - off the top of my head openvswitch comes to mind.
>>>> Then again, It's not as extensive as mesa :-\
>>>
>>> Just looked -- you know what their last commit to Makefile.am is?
>>>
>>> Makefile: Drop vestiges of support for non-GNU Make.
>>>
>> That's their decision. I am pointing out that one can have a sane
>> project w/o recursive makefiles, yet perfectly readable.
>>
>>>>> ... and with Meson it is tractable. And it doesn't use libtool. And it
>>>>> can replace at least 2 and maybe all three of our build systems.
>>>>>
>>>>> Those all seem extremely compelling to me, and I think I've done
>>>>> enough work on Mesa's build system and on a downstream distribution to
>>>>> have a valuable opinion on the matter.
>>>> Yes you did a lot of work on the autotools side, with less so on scons
>>>> and android.
>>>>
>>>> What I'm saying is - let us be mature and stop it with the [reasonable
>>>> or not] hatred towards autotools.
>>>
>>> Troll bait.
>>>
>> ? You're saying that nobody is bashing on autotools/friends... ok.
>
> They are not my favorite pieces of software and I think there are
> sound technical arguments in favor of Meson in comparison to them,
> which I and others have made repeatedly in this thread.
>
> None of that is immature.
>
Disagreeing with something/someone is fine, calling it names seems
immature... at least for me.
>>>> It is far from perfect, yet we can improve things on our end rather
>>>> than throwing everything in the bin.
>>>
>>> I have. Again, I think I have done enough of that that I have some
>>> credibility on the matter.
>>
>> Not trying to belittle any of your work, but this does not parse in
>> reply to my suggestion, sorry.
>>
>>
>> Overall your replies seem quite spontaneous/emotional. If I'm making
>> you upset - I do apologise.
>> I'm simply trying to get as much technical details, which I seems to
>> be tailing at.
>
> Let me try one last time:
>
> (1) Non-recursive automake is necessary for parallel build performance
Fully agree
> (2) Non-recursive automake is intractably unmaintainable for
> sufficiently large projects
Not sure I agree here. Do the src/intel/Makefile* files, seem unmaintainable ?
> (3) Mesa is a sufficiently large project
>
Again - fully agree.
> Therefore using automake will be either bad for parallel build
> performance, unmaintainable, or both.
>
> Meson aims to be a build system actually capable of replacing
> autotools (IMO unlike cmake, scons, waf, et al.). It offers a much
> cleaner domain specific language for writing the build rules, while
> generating non-recursive ninja build files. It does not use libtool.
> It supports Windows. It supports cross compilation.
>
Does it support, Darwin/MacOSX, Cygwin, any of the BSDs, Solaris (and
alike) platforms,
How about Android - Android.mk or Blueprint.
Does it have "dist", "check", "distcheck" or less commonly used
"ctags" "cscope" targets ?
> And it has momentum: libepoxy already has a Meson build system. Others
> in the X.Org community are experimenting with it for libinput, Wayland
> and Weston, and the xserver.
>
> All of that makes Meson very compelling.
That's the thing - I'm never said that it's _not_ a very compelling project.
I'm saying that it's not there yet - mostly due to the list above.
Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 18:56 ` [Mesa-dev] " Emil Velikov
@ 2017-03-21 19:08 ` Jason Ekstrand
2017-03-21 19:10 ` [Mesa-dev] " Matt Turner
1 sibling, 0 replies; 94+ messages in thread
From: Jason Ekstrand @ 2017-03-21 19:08 UTC (permalink / raw)
To: Emil Velikov; +Cc: ML mesa-dev, ML dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 15364 bytes --]
On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov <emil.l.velikov@gmail.com>
wrote:
> On 21 March 2017 at 18:06, Matt Turner <mattst88@gmail.com> wrote:
> > On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov <emil.l.velikov@gmail.com>
> wrote:
> >> On 21 March 2017 at 15:57, Matt Turner <mattst88@gmail.com> wrote:
> >>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <
> emil.l.velikov@gmail.com> wrote:
> >>>> On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
> >>>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <
> emil.l.velikov@gmail.com> wrote:
> >>>>>> Seems like we ended up all over the place, so let me try afresh.
> >>>>>>
> >>>>>> Above all:
> >>>>>> - Saying "I don't care" about your users is arrogant - let us _not_
> >>>>>> do that, please ?
> >>>>>
> >>>>> Let's be honest, the OpenBSD is subjecting itself to some pretty
> >>>>> arbitrary restrictions caused including Mesa in its core: 10+ year
> old
> >>>>> GCC,
> >>>> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> >>>> wasn't OpenBSD to blame here ;-)
> >>>>
> >>>>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
> >>>>> NetBSD keep Mesa as part of the core operating system, and as such
> >>>>> don't suffer from these problems.
> >>>>>
> >>>>> For better or worse, they have made their choices and they get to
> live
> >>>>> with them. We are not beholden to them.
> >>>>>
> >>>> Overall this hunk seems misplaced. I go agree that we should not cater
> >>>> for all their needs. At the same time, intentionally, breaking things
> >>>> while we all can coexist is very strange.
> >>>>
> >>>>>> Even Linux distribution maintainers have responded that "upstream
> does
> >>>>>> not care us", which is indicative that we should be more careful
> what
> >>>>>> we say.
> >>>>>
> >>>>> Citation needed.
> >>>>>
> >>>> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
> >>>> couple of instances where I've been contacted in private.
> >>>>
> >>>>>> For the rest - we're dealing with two orthogonal issues here:
> >>>>>>
> >>>>>> * Multiple build systems
> >>>>>> I believe we'll all agree that I might be the person who's been in
> all
> >>>>>> the build systems the most.
> >>>>>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that
> yet:
> >>>>>
> >>>>> No one is advocating dropping all of the existing build systems yet.
> >>>>>
> >>>>> This patch is an RFC for a smaller project to start the discussion
> about Mesa.
> >>>>>
> >>>>>> - [currently] there is no viable solution for Android
> >>>>>
> >>>>> Acknowledged. Dylan is going to see if this is something that can be
> >>>>> solved in upstream Meson.
> >>>>>
> >>>> I would suggest checking with Android people as well, as Meson.
> >>>> There's some plans on moving to yet another build system - Blueprint.
> >>>>
> >>>>>> - dropping the Autotools will lead to OpenBSD and NetBSD having to
> >>>>>> write one from scratch, IIRC Solaris/FreeBSD and others are in
> similar
> >>>>>> boat.
> >>>>>
> >>>>> Solaris is a closed source operating system whose developers do not
> >>>>> contribute to the project. We do not need to base our decisions on
> >>>>> them.
> >>>>>
> >>>>> Mesa is not subject to ridiculous requirements (like in the case of
> >>>>> OpenBSD) in FreeBSD and NetBSD.
> >>>> Again - not a requirement, but coexistence.
> >>>>
> >>>>> Mesa depends on gmake in FreeBSD's
> >>>>> ports, for instance.
> >>>>>
> >>>> That amongst others is a bug in their packaging.
> >>>
> >>> That is not even remotely the point.
> >>>
> >>> My point is that they are not subjecting themselves (and us by
> >>> extension, since you want to let them) to such ridiculous
> >>> requirements.
> >>>
> >> I will kindly ask you to keep these adjectives outside of what aims to
> >> be (?) technical discussion.
> >
> > Huh?
> >
> > Didn't you call us arrogant in this very thread? Didn't you suggest
> > we're immature?
> >
> Should I was unclear previously - I'm not trying to belittle, insult
> or otherwise offend your/anyone's contribution or input.
>
> I'm hoping to have a technical discussion, which does not have phrases
> such as "slow as mud" "i don't care", "X is ridiculous" and friends.
>
> >> And on your question - 50-100 lines worth of compatibility changes
> >> across a 6.5kloc of build system is not that unreasonable, right ?
> >
> > You're still not understanding my point.
> >
> >>>>> So I don't think any of this is true.
> >>>>>
> >>>> I'd suggest giving it a try then - grab a non-GNU make, a release
> >>>> tarball and let me know if you spot any issues.
> >>>>
> >>>>>> These projects have been getting closer to upstream and "forcing"
> the
> >>>>>> extra obstacle is effectively giving them the middle finger.
> >>>>>
> >>>>> No. Requiring us to compile with a 10 year old GCC is giving a
> middle finger.
> >>>>>
> >>>> Can we stop with the GCC thing ? Can we point to a place where we want
> >>>> to use feature A introduced with GCC B and we don't ?
> >>>
> >>> Are you freaking serious?!
> >>>
> >>> This happens *all* the time. It happened like two days ago with commit
> >>> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
> >>> happened at least once in the previous month, and every month before
> >>> that.
> >>>
> >> Considering none of the ANV code is built outside of Linux, why you
> >> guys will restrict yourself is beyond me.
> >
> > I think you're confused.
> >
> Can you elaborate ?
>
> You pointed out that we're restricting ourselves to old GCC version
> due to OpenBSD. Yet the example given is not code that is build, or
> expected to build soon on said platform.
> Hence, If you guys want to use functionality from GCC 4.7 [which I
> would encourage you to do] it would be better to add a 3 line
> configure check - just like st/nine and st/clover already do.
>
OpenBSD is currently carring patches against GCC 4.2 that improve
designated initializer support so that they can build our driver. (I think
it's required for NIR if I recall correctly.) We continue to accept
patches to keep it building on GCC 4.6 because some old versions of redhat
ship it and supporting it hasn't been a huge problem yet. That said...
Should we decide there's some feature in GCC 5 that would make our lives
way easier, we don't want people telling us we shouldn't because they have
some weird build requirements that prevent it.
Clearly, our driver builds on OpenBSD and it builds with their patched GCC
4.2. What we've been trying to say, however, is that "OpenBSD doesn't
package meson" or "OpenBSD don't have python in core" aren't sufficient
arguments to keep us using autotools if something significantly better
comes along. As far as I can tell, that is the only semi-technical
argument you've been making against meson in this discussion so far. It's
not a trump card.
I would much rather see us discuss the technical merits of meson vs. scons
vs. autoools vs. cmake as build systems rather than spend hundreds of lines
of e-mails arguing about whether or not OpenBSD and solaris can use it
without additional packaging work.
> >> Nine requires GCC 4.6 and Clover GCC 4.7 for a long time.
> >>
> >>>> The anonymous unions/structs for example require newer GCC and we use
> >>>> them extensively. If anything we have the workaround(s) for MSVC's
> >>>> lack of designated initializers.
> >>>
> >>> We actually have
> >>>
> >>> if test "x$USE_GNU99" = xyes; then
> >>> CFLAGS="$CFLAGS -std=gnu99"
> >>> else
> >>> CFLAGS="$CFLAGS -std=c99"
> >>> fi
> >>>
> >>> in configure.ac to work around gcc-4.4 incompatibilities.
> >>>
> >> 5-10 lines of configure code is not that much of a burden, right ?
> >
> > You're missing the point again.
> >
> >>>> Not to mention that some/many of the restrictions are imposed by very
> >>>> older enterprise linuxes.
> >>>
> >>> which eventually go out of support and those requirements disappear.
> >>> Unlike OpenBSD's insistence on using the last GPLv2 GCC.
> >>>
> >> At which point we can reconsider, right - perhaps they have the
> >> functionality backported, have moved to new version/another compiler
> >> etc.
> >
> > You're missing the point again.
> >
> Can you/anyone elaborate on this/other points that I'm missing ? Please ?
>
> >>>>>> * Slow build times
> >>>>>> Before we jump into "the next cool thing", let us properly utilise
> >>>>>> what we have at the moment.
> >>>>>
> >>>>> It cannot be properly utilized. There is a patch on the list *today*
> >>>>> that is attempting to workaround the *design* of libtool. It's an
> >>>>> issue that's existed... since libtool?
> >>>>>
> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=58664
> >>>>> https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
> >>>>>
> >>>> Yes design is ..., but I'm talking about utilising all the X cores on
> $platform.
> >>>>
> >>>>>> - I've asked multiple times about numbers behind those "let's make
> >>>>>> the build faster" patches, but never got any :-\
> >>>>>
> >>>>> What patches? The patches in this thread? What is your question?
> >>>>>
> >>>> Nearly every time we had a "let's remove this recursive Makefile"
> >>>> patch I asked "what improvement are we talking about here - how long
> >>>> does it take before/after this patch to build mesa".
> >>>> I'm yet to see any numbers :-\
> >>>
> >>> Because it's basically always small.
> >> IIRC Jason, mentioned something similar to "loads" with the recent ANV
> >> move - silly me cannot find the quote :-\
> >>
> >> Found another one though (from the glsl/nir move to compiler/)
> >>
> >> On 16 December 2015 at 20:24, Matt Turner <mattst88@gmail.com> wrote:
> >>> On Wed, Dec 16, 2015 at 8:53 AM, Emil Velikov <
> emil.l.velikov@gmail.com> wrote:
> >>
> >>> > Can anyone confirm how much of a penalty are we talking about (single
> >>> > vs separate makefiles) ?
> >>>
> >>> I'm not going to take the time to quantify it. Just do a clean build
> >>> and watch as 7 of your 8 cores sit idle as format_srgb.c is generated
> >>> or shared-glapi/libglapi.la is linked. (A dual-core system is not
> >>> going to demonstrate this issue properly)
> >>
> >> This is where I should have said - "I don't have a 8 core system, so I
> >> cannot measure it", although on your end one could have let it compile
> >> [say, during your lunch] and share with some numbers.
> >> Your reply is quite provocative and even if I've had an full-retard
> >> moment, I'm not sure that this is the way to reply.
> >>
> >>> The whole project needs to be
> >>> non-recursive, otherwise you get lots of little directories and stalls
> >>> (generating format_srgb comes to mind). All the work making things
> >>> non-recursive are opportunistic, and don't really address the
> >>> completely intractable nature of the problem: there are still 95
> >>> Makefile.ams.
> >>>
> >> Fully agree - those can be reworked, but I simply cannot measure any
> >> difference on the systems I have access to.
> >> Hence, cannot estimate the severity of the problem.
> >>
> >>>> Some cases that come to mind - mapi (gles1/2), glsl, nir and the
> latest ANV.
> >>>>
> >>>>>> - I can improve things but would need access to a fancy XX core
> >>>>>> system to do rudimentary benchmarks/checks and test patches.
> >>>>>
> >>>>> Have you ever seen an autotools build system for a project as complex
> >>>>> as Mesa that is both non-recursive and comprehensible? I have not,
> and
> >>>>> I did a lot of searching. In my opinion, this is an intractable
> >>>>> problem.
> >>>>>
> >>>> Haven't looked at all really - off the top of my head openvswitch
> comes to mind.
> >>>> Then again, It's not as extensive as mesa :-\
> >>>
> >>> Just looked -- you know what their last commit to Makefile.am is?
> >>>
> >>> Makefile: Drop vestiges of support for non-GNU Make.
> >>>
> >> That's their decision. I am pointing out that one can have a sane
> >> project w/o recursive makefiles, yet perfectly readable.
> >>
> >>>>> ... and with Meson it is tractable. And it doesn't use libtool. And
> it
> >>>>> can replace at least 2 and maybe all three of our build systems.
> >>>>>
> >>>>> Those all seem extremely compelling to me, and I think I've done
> >>>>> enough work on Mesa's build system and on a downstream distribution
> to
> >>>>> have a valuable opinion on the matter.
> >>>> Yes you did a lot of work on the autotools side, with less so on scons
> >>>> and android.
> >>>>
> >>>> What I'm saying is - let us be mature and stop it with the [reasonable
> >>>> or not] hatred towards autotools.
> >>>
> >>> Troll bait.
> >>>
> >> ? You're saying that nobody is bashing on autotools/friends... ok.
> >
> > They are not my favorite pieces of software and I think there are
> > sound technical arguments in favor of Meson in comparison to them,
> > which I and others have made repeatedly in this thread.
> >
> > None of that is immature.
> >
> Disagreeing with something/someone is fine, calling it names seems
> immature... at least for me.
>
> >>>> It is far from perfect, yet we can improve things on our end rather
> >>>> than throwing everything in the bin.
> >>>
> >>> I have. Again, I think I have done enough of that that I have some
> >>> credibility on the matter.
> >>
> >> Not trying to belittle any of your work, but this does not parse in
> >> reply to my suggestion, sorry.
> >>
> >>
> >> Overall your replies seem quite spontaneous/emotional. If I'm making
> >> you upset - I do apologise.
> >> I'm simply trying to get as much technical details, which I seems to
> >> be tailing at.
> >
> > Let me try one last time:
> >
> > (1) Non-recursive automake is necessary for parallel build performance
> Fully agree
>
> > (2) Non-recursive automake is intractably unmaintainable for
> > sufficiently large projects
> Not sure I agree here. Do the src/intel/Makefile* files, seem
> unmaintainable ?
>
Having to maintain full path names for everything is a pain. The
src/intel/Makefile.*.am files are mostly ok because they only go one
level. It's a bit annoying, but we'll put up with it for the sake of
better build times. If we tried to do that to the entire tree, I don't see
a way that it isn't a disaster.
> > (3) Mesa is a sufficiently large project
> >
> Again - fully agree.
>
> > Therefore using automake will be either bad for parallel build
> > performance, unmaintainable, or both.
> >
> > Meson aims to be a build system actually capable of replacing
> > autotools (IMO unlike cmake, scons, waf, et al.). It offers a much
> > cleaner domain specific language for writing the build rules, while
> > generating non-recursive ninja build files. It does not use libtool.
> > It supports Windows. It supports cross compilation.
> >
> Does it support, Darwin/MacOSX, Cygwin, any of the BSDs, Solaris (and
> alike) platforms,
> How about Android - Android.mk or Blueprint.
> Does it have "dist", "check", "distcheck" or less commonly used
> "ctags" "cscope" targets ?
>
> > And it has momentum: libepoxy already has a Meson build system. Others
> > in the X.Org community are experimenting with it for libinput, Wayland
> > and Weston, and the xserver.
> >
> > All of that makes Meson very compelling.
> That's the thing - I'm never said that it's _not_ a very compelling
> project.
> I'm saying that it's not there yet - mostly due to the list above.
>
> Thanks
> Emil
>
[-- Attachment #1.2: Type: text/html, Size: 21557 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 18:56 ` [Mesa-dev] " Emil Velikov
2017-03-21 19:08 ` Jason Ekstrand
@ 2017-03-21 19:10 ` Matt Turner
2017-03-22 17:16 ` Emil Velikov
1 sibling, 1 reply; 94+ messages in thread
From: Matt Turner @ 2017-03-21 19:10 UTC (permalink / raw)
To: Emil Velikov; +Cc: ML mesa-dev, ML dri-devel, Jason Ekstrand, Dylan Baker
On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> On 21 March 2017 at 18:06, Matt Turner <mattst88@gmail.com> wrote:
>> (1) Non-recursive automake is necessary for parallel build performance
> Fully agree
>
>> (2) Non-recursive automake is intractably unmaintainable for
>> sufficiently large projects
> Not sure I agree here. Do the src/intel/Makefile* files, seem unmaintainable ?
Not by itself.
src/intel only accounts for 70 thousand lines of code. Mesa is 1.25 million.
>> (3) Mesa is a sufficiently large project
>>
> Again - fully agree.
>
>> Therefore using automake will be either bad for parallel build
>> performance, unmaintainable, or both.
>>
>> Meson aims to be a build system actually capable of replacing
>> autotools (IMO unlike cmake, scons, waf, et al.). It offers a much
>> cleaner domain specific language for writing the build rules, while
>> generating non-recursive ninja build files. It does not use libtool.
>> It supports Windows. It supports cross compilation.
>>
> Does it support, Darwin/MacOSX, Cygwin, any of the BSDs, Solaris (and
> alike) platforms,
Its website says "Linux, OSX, Windows, Gcc, Clang, Visual Studio and
others". I see Meson in FreeBSD's ports. It's written in python, so I
expect it will support any of the platforms we care about.
> How about Android - Android.mk or Blueprint.
We have gone over this.
> Does it have "dist", "check", "distcheck" or less commonly used
Our thinking is that by switching to a build system that doesn't
require large amounts of generated code (configure, Makefile.in, etc),
we will stop shipping the code generated by the build system in the
tarballs (which would just be created by git archive). None of that is
set in stone.
> "ctags" "cscope" targets ?
I don't know.
>> And it has momentum: libepoxy already has a Meson build system. Others
>> in the X.Org community are experimenting with it for libinput, Wayland
>> and Weston, and the xserver.
>>
>> All of that makes Meson very compelling.
> That's the thing - I'm never said that it's _not_ a very compelling project.
> I'm saying that it's not there yet - mostly due to the list above.
Perfect. Since no one claimed it's "there yet" there is nothing to
disagree about.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 18:36 ` [Mesa-dev] " Kai Wasserbäch
@ 2017-03-21 21:16 ` Dylan Baker
0 siblings, 0 replies; 94+ messages in thread
From: Dylan Baker @ 2017-03-21 21:16 UTC (permalink / raw)
To: Kai Wasserbäch, dri-devel, mesa-dev
[-- Attachment #1.1: Type: text/plain, Size: 2857 bytes --]
Hey Kai,
Quoting Kai Wasserbäch (2017-03-21 11:36:31)
> I hope the rest of the Mesa project would follow such a rule. Because if there's
> something I absolutely hate about all those "new" build systems, then it's their
> tendency to just download stuff and build/include that. This seems to have risen
> with Node and now spread into Rust and other parts of the FLOSS eco-system.
I think we have enough distro people in the project that they would revert a use
of wrap on linux :)
> CMake or SCons would do the same AFAICS. Plus CMake seems to be used in the
> Android eco-system already
> (<https://developer.android.com/ndk/guides/cmake.html>), which might mean it
> could be easier for the Android downstreams of Mesa? Not sure on that though.
I don't think this really helps our android problem, since mesa is part of the
core anrdoid tree for devices using mesa, it needs android.mk files (I think
someone mentioned that they're migrating to blueprint?), and that doesn't
support cmake, autotools, scons, or meson. If meson is useful I'm willing to
propose and write an android.mk or blueprint backend for meson if the meson
community wants it.
> > 2) meson much simpler than autotools, scons, or (especially) cmake
>
> OTOH CMake gives you CTest/CDash
> (<https://cmake.org/cmake/help/latest/manual/ctest.1.html>), CPack
> (<https://cmake.org/cmake/help/latest/manual/cpack.1.html>), dependency
> visualisation
> (<https://cmake.org/cmake/help/latest/module/CMakeGraphVizOptions.html>) and
> many other things for (basically) free. Maybe that warrants some complexity?
Meson generates a 'ninja test' target, and has a mesontest which I assume is
similar to CTest, but I've never used mesontest or CTest tbh, so I can't comment
too much about either.
> > 3) recursive meson files, flat ninja file.
>
> IIRC you would also get the same with CMake if you target Ninja.
That's fair.
> >
> > I've never had to use gitattributes for anything, are you thinking for setting
> > export-ignore and export-subst?
>
> Yep. AFAICT we have several files which aren't distributed if you do "make
> dist". Those would need to be excluded from a tarball built with git archive as
> well. AFAIK that's done through having .gitattributes files in the tree.
I'll have a look at what ends up in the dist-tarball and what ends up in a
git-archive tarbal too. Thanks for pointing that out.
> Anyway, I don't want to bikeshed here, so I'll be silent as long as any possible
> future build system doesn't download stuff behind my back.
>
> Thanks for your reply!
>
> Cheers,
> Kai
Thanks for your reply Kai, I hadn't even noticed wrap, so at the very least it's
good to see that's there, and I'll be sure to add a note to the README that we
don't use wrap on Linux, BSD and similar.
Dylan
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljRmCAACgkQCJ4WlhQG
iO9aTAf/cDTlepX1CnpuXTYaMAyhdhKvFoxCP7sbXbaacjsQOt/pe080SSbkovZx
kNmU7vEO35hC0CCr2x+q6n0XuZRuEpLIcpvYB0Bal0bw3voZSl6DwQjLNGm5BZVE
QjyYoaeVUs9PVXvxtPv7Q2pXESdF7kN1KQkSm5jpGeFE8ASR2kP9qne3OLfLcq+P
y7fZDko3OwxFn1/D6sqsTVV1BZ5snpS0ZsL1PSc/8lRppvFv9jIDWG1pz3vIAbNr
zFRVhtqqWgBJmF3DcnfPQvKDvbkPclczf/LVoTjsj6Vmv1JvtNrFv6C/3LZ87eiu
wcWU+bf7V4oXSl7sMU28E3/+aO0YeQ==
=GFv7
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 16:22 ` Dylan Baker
@ 2017-03-22 4:23 ` Jonathan Gray
2017-03-22 8:24 ` Jani Nikula
1 sibling, 0 replies; 94+ messages in thread
From: Jonathan Gray @ 2017-03-22 4:23 UTC (permalink / raw)
To: Dylan Baker; +Cc: mesa-dev, dri-devel
On Tue, Mar 21, 2017 at 09:22:50AM -0700, Dylan Baker wrote:
> Quoting Jani Nikula (2017-03-21 07:44:55)
> > On Thu, 16 Mar 2017, Dylan Baker <dylan@pnwbakers.com> wrote:
> > > First it's written in python, [...]
> >
> > How does meson handle python 2 vs. 3? How do you avoid issues in the
> > build files wrt this? On Debian meson seems to depend on python 3, so
> > are they fully python 3?
>
> Meson requires python 3.4+, and doesn't support python 2. Python 3.4 was
> released in 2012. It's also worth nothing that a couple of us have been working
> to get mesa's python scripts python3 compatible, so in the (hopefully) near
> future python2 wouldn't be required.
Mesa only requires python for development versions not to build
releases. Changing to a build system that uses python3 to parse JSON
like files to generate ninja would change that.
>
> > How does meson handle build file backwards compatibility between meson
> > versions? I don't intend to flame, but I've found for some reason many
> > python projects don't seem to take this very seriously. Either having
> > conditionals in build files to support building with several meson
> > versions or always requiring the latest and greatest version would be
> > rather annoying.
>
> Meson makes backwards compatible changes, and the version can be queried using
> `meson.version()`, which works using meson's version comparison mechanism. I
> would say this about meson, it's not a 'python project', it's 'a project written
> in python', and they've taken great pains to not expose python in meson, and
> reserve the right to reimplement in a different language if python becomes an
> issue.
>
>
> > BR,
> > Jani.
> >
> > --
> > Jani Nikula, Intel Open Source Technology Center
>
> Dylan
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 16:22 ` Dylan Baker
2017-03-22 4:23 ` [Mesa-dev] " Jonathan Gray
@ 2017-03-22 8:24 ` Jani Nikula
2017-03-22 21:05 ` Dylan Baker
1 sibling, 1 reply; 94+ messages in thread
From: Jani Nikula @ 2017-03-22 8:24 UTC (permalink / raw)
To: Dylan Baker, dri-devel; +Cc: mesa-dev
On Tue, 21 Mar 2017, Dylan Baker <dylan@pnwbakers.com> wrote:
> Quoting Jani Nikula (2017-03-21 07:44:55)
>> How does meson handle build file backwards compatibility between meson
>> versions? I don't intend to flame, but I've found for some reason many
>> python projects don't seem to take this very seriously. Either having
>> conditionals in build files to support building with several meson
>> versions or always requiring the latest and greatest version would be
>> rather annoying.
>
> Meson makes backwards compatible changes, and the version can be
> queried using `meson.version()`, which works using meson's version
> comparison mechanism. I would say this about meson, it's not a 'python
> project', it's 'a project written in python',
This is what I meant above, although I clearly didn't write it that way.
> and they've taken great pains to not expose python in meson, and
> reserve the right to reimplement in a different language if python
> becomes an issue.
Right. That helps avoid many of the issues e.g. Sphinx has with the
configuration files being pure python.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-16 21:25 [RFC libdrm 0/2] Replace the build system with meson Dylan Baker
` (6 preceding siblings ...)
2017-03-21 16:50 ` Kai Wasserbäch
@ 2017-03-22 16:40 ` Alex Deucher
2017-03-22 17:07 ` Rob Clark
2017-03-22 22:30 ` [Mesa-dev] " Eric Anholt
7 siblings, 2 replies; 94+ messages in thread
From: Alex Deucher @ 2017-03-22 16:40 UTC (permalink / raw)
To: Dylan Baker; +Cc: mesa-dev, Maling list - DRI developers
On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
> Why bother, and why would we want this? │~
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently. Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
>
> What's different about using meson?
>
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D<opt>=<value> more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?
>
> Here are the performance numbers I see on a 2 core 4 thread SKL, without
> initial configuration, and building out of tree (using zsh):
>
> For meson the command line is:
> time (meson build -Dmanpages=true && ninja -C build)
>
> For autotools the command line is:
> time (mdkir build && cd build && ../autotools && make -j5 -l4)<Paste>
>
> meson (cold ccache): 13.37s user 1.74s system 255% cpu 5.907 total
> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> meson (hot ccache): 2.13s user 0.39s system 154% cpu 1.633 total
> autotools (hot ccache): 13.93s user 0.73s system 102% cpu 14.259 total
>
> That's ~4x faster for a cold build and ~10x faster for a hot build.
>
> For a make clean && make style build with a hot cache:
> meson: 4.64s user 0.33s system 334% cpu 1.486 total
> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>
> Why bother with libdrm?
>
> It's a simple build system, that could be completely (or mostly
> completely) be ported in a very short time, and could serve as a tech
> demo for the advantages of using meson to garner feedback for embarking
> on a larger project, like mesa (which is what I'm planning to work on
> next).
>
> tl;dr
>
> I wrote this as practice for porting Mesa, and figured I might as well
> send it out since I wrote it.
>
> It is very likely that neither of these large patches will show up on the
> mailing list, but this is available at my github:
> https://github.com/dcbaker/libdrm wip/meson
I guess I'm a little late to the party here, but I haven't had time to
really let all of this sink in and actually look at meson. It doesn't
seem so bad with a quick look and I think I could probably sort it out
when the time came, but there would still be a bit of a learning
curve. While that may not be a big deal at the micro level, I have
concerns at the macro level.
First, I'm concerned it may discourage casual developers and
packagers. autotools isn't great, but most people are familiar enough
with it that they can get by. Most people have enough knowledge of
autotools that they can pretty easily diagnose a configuration based
failure. There are a lot of resources for autotools. I'm not sure
that would be the case for meson. Do we as a community feel we have
enough meson experience to get people over the hump? Anything that
makes it harder for someone to try a new build or do a bisect is a big
problem in my opinion.
Next, my bigger concern is for distro and casual packagers and people
that maintain large build systems with lots of existing custom
configurations. Changing from autotools would basically require many
of these existing tools and systems to be rewritten and then deal with
the debugging and fall out from that. The potential decreased build
time is a nice bonus, but frankly a lot of people/companies have years
of investment in existing tools.
my 2 cents.
Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 16:40 ` Alex Deucher
@ 2017-03-22 17:07 ` Rob Clark
2017-03-22 20:10 ` [Mesa-dev] " Dylan Baker
2017-03-22 22:30 ` [Mesa-dev] " Eric Anholt
1 sibling, 1 reply; 94+ messages in thread
From: Rob Clark @ 2017-03-22 17:07 UTC (permalink / raw)
To: Alex Deucher; +Cc: mesa-dev, Maling list - DRI developers
On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
>> Why bother, and why would we want this? │~
>>
>> First it's written in python, which means the potential developer base
>> is massive. And it provides a recursive view for humans, but a
>> non-recursive view for the system. This is the best of both worlds,
>> humans can organize the build system in a way that makes sense, and the
>> machine gets a non-recursive build system. It also uses ninja rather
>> than make, and ninja is faster than make inherently. Meson is also a
>> simpler syntax than autotools or cmake it's not Turing Complete by
>> design nor does it expose python, again, by design. This allows meson
>> itself to be reimplemented in a another language if python becomes a
>> dead-end or a bottle-neck. It also makes it much easier to understand
>> what the build system is doing.
>>
>> What's different about using meson?
>>
>> Well, apart from a faster builds and less magic in the build system? The
>> configure flags are different, it uses -D<opt>=<value> more like cmake
>> than the --enable or --with flags of autotools, although oddly it uses
>> --prefix and friends when calling meson, but not with mesonconf, there's
>> a bug opened on this. Meson also doesn't support in-tree builds at all;
>> all builds are done out of tree. It also doesn't provide a "make dist"
>> target, fortunately there's this awesome tool called git, and it
>> provides a "git archive" command that does much the same thing. Did I
>> mention it's fast?
>>
>> Here are the performance numbers I see on a 2 core 4 thread SKL, without
>> initial configuration, and building out of tree (using zsh):
>>
>> For meson the command line is:
>> time (meson build -Dmanpages=true && ninja -C build)
>>
>> For autotools the command line is:
>> time (mdkir build && cd build && ../autotools && make -j5 -l4)<Paste>
>>
>> meson (cold ccache): 13.37s user 1.74s system 255% cpu 5.907 total
>> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
>> meson (hot ccache): 2.13s user 0.39s system 154% cpu 1.633 total
>> autotools (hot ccache): 13.93s user 0.73s system 102% cpu 14.259 total
>>
>> That's ~4x faster for a cold build and ~10x faster for a hot build.
>>
>> For a make clean && make style build with a hot cache:
>> meson: 4.64s user 0.33s system 334% cpu 1.486 total
>> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>>
>> Why bother with libdrm?
>>
>> It's a simple build system, that could be completely (or mostly
>> completely) be ported in a very short time, and could serve as a tech
>> demo for the advantages of using meson to garner feedback for embarking
>> on a larger project, like mesa (which is what I'm planning to work on
>> next).
>>
>> tl;dr
>>
>> I wrote this as practice for porting Mesa, and figured I might as well
>> send it out since I wrote it.
>>
>> It is very likely that neither of these large patches will show up on the
>> mailing list, but this is available at my github:
>> https://github.com/dcbaker/libdrm wip/meson
>
>
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson. It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve. While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers. autotools isn't great, but most people are familiar enough
> with it that they can get by. Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools. I'm not sure
> that would be the case for meson. Do we as a community feel we have
> enough meson experience to get people over the hump? Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.
>
> Next, my bigger concern is for distro and casual packagers and people
> that maintain large build systems with lots of existing custom
> configurations. Changing from autotools would basically require many
> of these existing tools and systems to be rewritten and then deal with
> the debugging and fall out from that. The potential decreased build
> time is a nice bonus, but frankly a lot of people/companies have years
> of investment in existing tools.
>
I guess an interesting question (from someone who doesn't know meson
yet) would be whether meson could slurp in the Makefile.sources type
stuff that we have, which are shared so far between
android/scons/autotools (and for the most part, kept developers from
having to care *too* much about the different build systems)
If so, that makes it easier to coexist with existing build systems. I
don't think it would be a good idea to remove the autotools build
anytime soon.. that should be the last one removed, after meson has
replaced scons (and hopefully android?)
BR,
-R
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 19:10 ` [Mesa-dev] " Matt Turner
@ 2017-03-22 17:16 ` Emil Velikov
0 siblings, 0 replies; 94+ messages in thread
From: Emil Velikov @ 2017-03-22 17:16 UTC (permalink / raw)
To: Matt Turner; +Cc: ML mesa-dev, ML dri-devel, Jason Ekstrand, Dylan Baker
On 21 March 2017 at 19:10, Matt Turner <mattst88@gmail.com> wrote:
> On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> On 21 March 2017 at 18:06, Matt Turner <mattst88@gmail.com> wrote:
>>> (1) Non-recursive automake is necessary for parallel build performance
>> Fully agree
>>
>>> (2) Non-recursive automake is intractably unmaintainable for
>>> sufficiently large projects
>> Not sure I agree here. Do the src/intel/Makefile* files, seem unmaintainable ?
>
> Not by itself.
>
> src/intel only accounts for 70 thousand lines of code. Mesa is 1.25 million.
>
Perfect - I can sort out the ~60 gallium Makefiles which constitutes
in ~half of mesa quite quickly.
As those are sorted I'll look at the more picky ones and ensuring that
the contains remain as trivial as possible.
Will you/anyone be interested in skimming through the patches ?
>> Does it have "dist", "check", "distcheck" or less commonly used
>
> Our thinking is that by switching to a build system that doesn't
> require large amounts of generated code (configure, Makefile.in, etc),
> we will stop shipping the code generated by the build system in the
> tarballs (which would just be created by git archive). None of that is
> set in stone.
>
Where can I read-up on the discussion ?
Would be great if we don't bring back the flex/bison/other requirement
for people building from tarballs. Still ... there may be some good
arguments against that.
>> "ctags" "cscope" targets ?
>
> I don't know.
>
>>> And it has momentum: libepoxy already has a Meson build system. Others
>>> in the X.Org community are experimenting with it for libinput, Wayland
>>> and Weston, and the xserver.
>>>
>>> All of that makes Meson very compelling.
>> That's the thing - I'm never said that it's _not_ a very compelling project.
>> I'm saying that it's not there yet - mostly due to the list above.
>
> Perfect. Since no one claimed it's "there yet" there is nothing to
> disagree about.
Ack. In the interim we can make our existing build more performant, right ?
Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-16 22:36 ` Marek Olšák
2017-03-16 23:11 ` Dylan Baker
@ 2017-03-22 17:26 ` Jose Fonseca
2017-03-22 17:50 ` [Mesa-dev] " Marek Olšák
1 sibling, 1 reply; 94+ messages in thread
From: Jose Fonseca @ 2017-03-22 17:26 UTC (permalink / raw)
To: Marek Olšák, Dylan Baker; +Cc: mesa-dev, dri-devel
On 16/03/17 22:36, Marek Olšák wrote:
> Is there a way not to use ninja with meson, because ninja redirects
> all stderr output from gcc to stdout, which breaks many development
> environments that expect errors in stderr?
>
> I'm basically saying that if ninja can't keep gcc errors in stderr, I
> wouldn't like any project that I might be involved in to require ninja
> for building.
>
> Marek
Yes, that's an annoying behavior from ninja.
I use a simple shell script for IDEs that care about that (e.g., with
QtCreator):
$ cat `which ninja-stderr `
#!/bin/sh
ninja "$@" 1>&2
There's a rationale for ninja to behave like that -- ninja buffers the
whole program output, but and they use a combined buffer for both stderr
and stdout so lines appear in same order. Still, it would be nice if
they fixed this for everybody.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 17:26 ` Jose Fonseca
@ 2017-03-22 17:50 ` Marek Olšák
0 siblings, 0 replies; 94+ messages in thread
From: Marek Olšák @ 2017-03-22 17:50 UTC (permalink / raw)
To: Jose Fonseca; +Cc: mesa-dev, dri-devel, Dylan Baker
On Wed, Mar 22, 2017 at 6:26 PM, Jose Fonseca <jfonseca@vmware.com> wrote:
> On 16/03/17 22:36, Marek Olšák wrote:
>>
>> Is there a way not to use ninja with meson, because ninja redirects
>> all stderr output from gcc to stdout, which breaks many development
>> environments that expect errors in stderr?
>>
>> I'm basically saying that if ninja can't keep gcc errors in stderr, I
>> wouldn't like any project that I might be involved in to require ninja
>> for building.
I also use Qt Creator.
Here is the ninja branch that keeps errors in stderr:
https://github.com/dendy/ninja/tree/segmented-output
Marek
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-17 2:28 ` Brian Paul
@ 2017-03-22 17:59 ` Jose Fonseca
2017-03-22 20:57 ` [Mesa-dev] " Dylan Baker
0 siblings, 1 reply; 94+ messages in thread
From: Jose Fonseca @ 2017-03-22 17:59 UTC (permalink / raw)
To: Brian Paul, Jason Ekstrand; +Cc: ML mesa-dev, Emil Velikov, ML dri-devel
On 17/03/17 02:28, Brian Paul wrote:
> On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand <jason@jlekstrand.net
> <mailto:jason@jlekstrand.net>> wrote:
>
> On March 16, 2017 5:41:24 PM Emil Velikov <emil.l.velikov@gmail.com
> <mailto:emil.l.velikov@gmail.com>> wrote:
>
> On 17 March 2017 at 00:21, Dylan Baker <dylan@pnwbakers.com
> <mailto:dylan@pnwbakers.com>> wrote:
>
> Hi Emil,
>
> Quoting Emil Velikov (2017-03-16 16:35:33)
>
> While I can see you're impressed by Meson, I would
> kindly urge you to
> not use it here. As you look closely you can see that
> one could
> trivially improve the times, yet the biggest thing is
> that most of the
> code in libdrm must go ;-)
>
>
> Perhaps I wasn't clear enough, I don't really expect this to
> land ever. I sent
> it out more because I'd written it and it works and is a
> useful demonstration of
> meson+ninja performance. Obviously 20 seconds -> 5 seconds
> isn't a huge deal :);
> but in a larger project, consider that a 4x speedup would be
> 4 minutes to 1
> minute, and that is a huge difference in time.
>
> You are still failing to see past your usecase. As said before - if
> there's any need to improve things say so.
> Note that you simply cannot apply the 1000x speedup in any
> situation.
>
>
> Yes, you can't just linearly apply any scaling factor. However,
> when you build mesa on a machine with a decent number of threads (I
> think our build machine for the CI system has 32 threads),
> autotools+make is slow as mud. Also, there's very little you can do
> to speed up configure since it's a pile of shell and perl that
> inherently runs single-threaded and is fairly complex due to mesa's
> complicated dependencies.
>
> As the port is not 1:1 wrt the autoconf one, the
> performance numbers
> above are comparing apples to oranges.
>
>
> I fail to see what I'm missing from meson that would have an
> effect on the
> times I reported. There are some files that are installed by
> autoconf that I
> didn't bother to install with meson (because I don't expect
> this to land). Since
> I didn't time installs, I don't see how it isn't an apples
> to apples comparison.
>
> You already (explicitly) mentioned some differences. Admittedly
> not a
> deal breaker.
>
> I understand that libdrm is a pessimal case for
> recursive-make since most
> sub folders contain < 5 C files, However, even if you were
> to flatten the make
> files meson+ninja would still be faster when you consider
> that meson
> configures and builds faster than autotools configures.
>
> That's correct. If is so concerned - they should slim down the
> configure.ac <http://configure.ac> ;-)
>
>
> There are real limits as to what you can do there.
>
> If you/others are unhappy with the build times of libdrm
> - poke me on
> IRC. I will give you some easy tips on how to improve those.
>
> You have some good python knowledge - I would kindly
> urge you to
> improve/rewrite the slow and/or hacky python scripts we
> have in mesa.
> This is a topic that was mentioned multiple times, and a
> part where
> everyone will be glad to see some progress.
>
> Thanks
> Emil
>
>
> The real goal here is to do mesa (in case I didn't make that
> clear either), and
> the advantage for mesa is not just performance, it's that
> meson supports visual
> studio on windows; which means that we could hopefully not
> just get faster
> builds, but also replace both autotools and scons with a
> single build system.
>
> Yes that was more than clear. Yet it won't fly, I'm afraid.
>
> The VMWare people like their SCons,
??
>
> How much? I would really rather the VMWare people speak on behalf
> of VMWare. Meson is the single best shot we've ever had for
> replacing both with one build system. I'm sure the VMware people
> would like to have a build system that gets maintained by the
> community as a whole.
>
>
> Sure, I'd like to see one build system instead of two. Meson supports
> Windows so that's good. But the big issue is our automated build
> system. Replacing SCons with Meson could be a big deal in that
> context. It would at least involve pulling Meson into our toolchain and
> rewriting a bunch of Python code to grok Meson. I'd have to go off and
> investigate that to even see if it's a possibility. Maybe next week.
I don't have any experience with Meson. But for the record I don't have
much love for SCons. I long stopped using SCons for anything but Mesa.
And my have good experience with cmake + ninja/msvc is positive. So
tools with similar architecture sound good overall.
In fact, knowing what I know now, if I could go back in time, to when I
evaluated CMake and SCons, I'd chose CMake.
BTW, it seems that newer SCons will drop Python 2 support [1], which
might force us to rewrite a lot of SConsfiles/scripts any way. So
perhaps that's a good time to evaluate migrating to something else.
That said, moving to another build system is always a herculian task.
Thought the benefit of having a single build system is appealing and
might save time down the line.
But there are many questions I have about Meson: how confident are we
on Meson? Are big projects using it? How sure are we that it won't
become abandonware in a few years time? How does it compare with other
newer gen build systems?
We also have special requirements: one is cross-build from Linux to
MinGW, which on Mesa case requires building portions of the tree twice
-- once for host -- another for cross-mingw.
Jose
[1] http://scons.org/scons-251-is-available.html
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 17:07 ` Rob Clark
@ 2017-03-22 20:10 ` Dylan Baker
2017-03-22 21:48 ` Rob Clark
` (2 more replies)
0 siblings, 3 replies; 94+ messages in thread
From: Dylan Baker @ 2017-03-22 20:10 UTC (permalink / raw)
To: Alex Deucher, Rob Clark; +Cc: mesa-dev, Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 4737 bytes --]
On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson. It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve. While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers. autotools isn't great, but most people are familiar enough
> with it that they can get by. Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools. I'm not sure
> that would be the case for meson. Do we as a community feel we have
> enough meson experience to get people over the hump? Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.
One of the things that's prompted this on our side (I've talked this over with
other people at Intel before starting), was that clearly we *don't* know
autotools well enough to get it right. Emil almost always finds cases were we've
done things *almost*, but not quite right.
For my part, it took me about 3 or 4 days of reading through the docs and
writing the libdrm port to get it right, and a lot of that is just the
boilerplate of having ~8 drivers that all need basically the same logic.
> Next, my bigger concern is for distro and casual packagers and people
> that maintain large build systems with lots of existing custom
> configurations. Changing from autotools would basically require many
> of these existing tools and systems to be rewritten and then deal with
> the debugging and fall out from that. The potential decreased build
> time is a nice bonus, but frankly a lot of people/companies have years
> of investment in existing tools.
Sure, but we're also not the only ones investigating meson. Gnome is using it
already, libepoxy is using it, gstreamer is using it. There are patches for
weston (written by Daniel Stone) and libinput (written by Peter Hutterer), there
are some other projects in the graphics sphere that people are working on. So
even if we as a community decide that meson isn't for us, it's not going away.
Quoting Rob Clark (2017-03-22 10:07:54)
> I guess an interesting question (from someone who doesn't know meson
> yet) would be whether meson could slurp in the Makefile.sources type
> stuff that we have, which are shared so far between
> android/scons/autotools (and for the most part, kept developers from
> having to care *too* much about the different build systems)
Jason and I have talked about that too. I'd suggested that we could write a
module for meson to read makefile.sources (since we're surely not the only
project that would benefit from such a module), except that android is moving to
blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't
support using makefile.sources, so it seems somewhat moot in a world of
blueprint for android, meson for *.
I don't think that meson should try to generate blueprint files, since blueprint
is itself a metabuild system that generates ninja files, and is self
boot-strapping Go code. I don't know if the community is going to want blueprint
to live in repo either, since one actually writes Go code for the build system.
(I'm not objecting prematurely, I'm just pointing out that the design is
significantly different the Android.mk, and the community will probably want to
re-evaluate)
If android doesn't mandate a migration to blueprint, or blueprint does handle
makefile.sources (I don't think it does), I'd be happy to propose a module for
meson that could read makefile.sources, and write said module, and get said
module upstream.
[1] https://godoc.org/github.com/google/blueprint
>
> If so, that makes it easier to coexist with existing build systems. I
> don't think it would be a good idea to remove the autotools build
> anytime soon.. that should be the last one removed, after meson has
> replaced scons (and hopefully android?)
I would imagine that if we did merge meson, we would make at the very least one
release with meson and autotools (scons is VMWare's thing, they can migrate at
their leisure), if not two, to give us a chance to flush out the bugs and to
give various distros who don't have meson ready yet a chance. It'll also give
the fast moving and aggressive distros like Arch and Fedora and chance to
migrate and report bugs.
Dylan
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljS2iYACgkQCJ4WlhQG
iO850wf8DJMpoNlKFu/vqC5BRmp6+jT57dfq4ayrzjlceeHYtYANDp91DoYzaJyB
STQ2H84K8f7bcpJkIuh58bhJm+udtqskXErSJCjC4VzeStKiFC+J0k+PqgaOSR7x
B0oT2EJ/c77gw9PU22SlTAjXTcalCIa7Me0ehLBEgv1LgSg4PewKot1/Jeavs+60
ED3wYLBMo9aUoU+MSnzXKI2PAjNZjnQSVJQB5J0Tzhp1UAf4rPjD6qwJ4M2EMEbw
wLsvx4XqXInkVpTzVggld14OwkB5UidEt1soi50Bhwe8GunFDJ95qT3BRCpdKwYF
v+KZsjgwusbvJktPZ6W5w1/Cdd4MWA==
=QWz+
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 17:59 ` Jose Fonseca
@ 2017-03-22 20:57 ` Dylan Baker
2017-03-22 22:02 ` Rob Clark
2017-03-24 14:03 ` Jose Fonseca
0 siblings, 2 replies; 94+ messages in thread
From: Dylan Baker @ 2017-03-22 20:57 UTC (permalink / raw)
To: Brian Paul, Jason Ekstrand, Jose Fonseca
Cc: ML mesa-dev, Emil Velikov, ML dri-devel
[-- Attachment #1.1: Type: text/plain, Size: 4331 bytes --]
Quoting Jose Fonseca (2017-03-22 10:59:10)
> On 17/03/17 02:28, Brian Paul wrote:
> >
> > [snip]
> >
> > Sure, I'd like to see one build system instead of two. Meson supports
> > Windows so that's good. But the big issue is our automated build
> > system. Replacing SCons with Meson could be a big deal in that
> > context. It would at least involve pulling Meson into our toolchain and
> > rewriting a bunch of Python code to grok Meson. I'd have to go off and
> > investigate that to even see if it's a possibility. Maybe next week.
>
>
> I don't have any experience with Meson. But for the record I don't have
> much love for SCons. I long stopped using SCons for anything but Mesa.
>
> And my have good experience with cmake + ninja/msvc is positive. So
> tools with similar architecture sound good overall.
>
> In fact, knowing what I know now, if I could go back in time, to when I
> evaluated CMake and SCons, I'd chose CMake.
>
>
> BTW, it seems that newer SCons will drop Python 2 support [1], which
> might force us to rewrite a lot of SConsfiles/scripts any way. So
> perhaps that's a good time to evaluate migrating to something else.
>
>
>
> That said, moving to another build system is always a herculian task.
> Thought the benefit of having a single build system is appealing and
> might save time down the line.
>
>
>
> But there are many questions I have about Meson: how confident are we
> on Meson? Are big projects using it? How sure are we that it won't
> become abandonware in a few years time? How does it compare with other
> newer gen build systems?
>
Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
Notably gnome is moving to meson (and some parts already use it), weston and
libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
can't say for sure it's going to be around forever, but its been in development
since late 2012 and still lands several patches a day, they were responsive to
me when I sent a patch (that I still need to respin), and they seem to be
picking up momentum from downstreams.
As to how it compares to other build systems, it's fairly different than cmake
and scons, it's much less scripting and much more declarative, you can look at
the libdrm patch or the meson in libepoxy (which is more mature) to see the
syntax. It doesn't expose python or a full scripting language, though it does
have some fairly simple logic like if/elif/else and foreach, and they support
modules that add functionality, but need to be merged upstream, this is how
pkgconfig writing is implemented, for example. One of the things that it does
better than autotools and (IMHO) cmake, is dependency management, in most cases
it requires no special handling, the only case it does in mesa (so far) is for
local python module dependencies in generators. I think that these are actually
strengths of meson, it's simplicity makes it easy to understand and use.
For support, it's written in pure python (using only the stdlib with no
external deps), and requires python 3.4+. It has backends for ninja on Linux,
ninja and visual studio on Windows, and xcode on macOS; Clang, GCC, and MSVC
are considered first class compilers, some others might work, but are
unsupported.
I have a partial port of piglit to meson that I put together to see what
porting from cmake to meson was like (with no plans to send to the list), I can
push that somewhere for you to look at if you want to see the difference.
>
> We also have special requirements: one is cross-build from Linux to
> MinGW, which on Mesa case requires building portions of the tree twice
> -- once for host -- another for cross-mingw.
Cross compiling for mingw is supported, and it provides a way to differentiate
the build, host, and target machines [1], I've cross compiled for
aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag for
this, but the meson approach is to write an ini file once, and use it again and
again), and the first example of cross compiling is using mingw from linux [2].
[1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
[2]https://github.com/mesonbuild/meson/wiki/Cross-compilation
Dylan
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljS5VcACgkQCJ4WlhQG
iO/hBQf/YjKOKw75ymG5rOvsj4dfyhJumbg2jK9TySz9TiX/U04OjoBeCmZQh/1w
P8iM0SMr8z+KtkUHy8cFf7ppYTc+kszP22OZuVCJ7gwyYnrpdeYn/Tt8qERqGMMo
JE8E6AX9bgVhBJVZULU4rgal2+Yw6Jgvhpncsog7fjFGBBs7LgduSl7uGIL4iVZ2
V2vA0Na6tzU8c9k0Gqen9HBe3+555L703nIpHbj/0hF6ZkQfWpDHptNWD3ESw7Vn
+/ZZMG+evn/R4eCwSDvMKs58eUaZqQ19WBKU2kzq1ag7QmPY2sbq1jWtrcaD1eMA
LsoCHnHbPyxKDJ3EkvLyFnriZ6xeWA==
=omZ1
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 8:24 ` Jani Nikula
@ 2017-03-22 21:05 ` Dylan Baker
2017-03-23 8:13 ` Jani Nikula
0 siblings, 1 reply; 94+ messages in thread
From: Dylan Baker @ 2017-03-22 21:05 UTC (permalink / raw)
To: Jani Nikula, dri-devel; +Cc: mesa-dev
[-- Attachment #1.1: Type: text/plain, Size: 1659 bytes --]
Quoting Jani Nikula (2017-03-22 01:24:19)
> On Tue, 21 Mar 2017, Dylan Baker <dylan@pnwbakers.com> wrote:
> > Quoting Jani Nikula (2017-03-21 07:44:55)
> >> How does meson handle build file backwards compatibility between meson
> >> versions? I don't intend to flame, but I've found for some reason many
> >> python projects don't seem to take this very seriously. Either having
> >> conditionals in build files to support building with several meson
> >> versions or always requiring the latest and greatest version would be
> >> rather annoying.
> >
> > Meson makes backwards compatible changes, and the version can be
> > queried using `meson.version()`, which works using meson's version
> > comparison mechanism. I would say this about meson, it's not a 'python
> > project', it's 'a project written in python',
>
> This is what I meant above, although I clearly didn't write it that way.
I don't think I was exactly clear in what I said either, I would describe SCons
as a "python project", and meson as a "project written in python", since SCons
is python and has some of the warts that make backwards compatibility in python
projects hard (changes that work in the majority case break in some niche use
cases), where meson has a parser/generator written in python.
> > and they've taken great pains to not expose python in meson, and
> > reserve the right to reimplement in a different language if python
> > becomes an issue.
>
> Right. That helps avoid many of the issues e.g. Sphinx has with the
> configuration files being pure python.
Yes, sphinx's configuration files are awful for just that reason.
Dylan
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljS5zQACgkQCJ4WlhQG
iO8ZpAf/WbCKhCm9hn4oSZGySDAq+HlkrPBlpIImJms2rjQ8KkaM0VuSFG/Nm2u8
7OmgPubwCe8mmBVcr2uK49dTQAT/IO3xCipHwylNQZa93Ojk78AqWgxVdnc7SQyc
GXhUhkWc1cMqTOQxuX9QapxkfkJkoQyew0p6W3I82e5ADxYsl6iHAVCZuuxYRW2l
FAMY/yPFq4T/7C9lS6n7zB9j2PPJu7fK4z0ItOhX/i+R2M6U0BJInjxku/We7ELa
Fj05gak3boSc2tTVnYbTCi7qlZ5Of+6B/eKjNPRZIlc9Fq9O7UXlYnIjVwhmOd5T
mjuPCrYMrETxWeQi16VxyMRB/qQGQw==
=y+sD
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 20:10 ` [Mesa-dev] " Dylan Baker
@ 2017-03-22 21:48 ` Rob Clark
2017-03-23 21:56 ` Greg Hackmann
2017-03-23 1:18 ` [Mesa-dev] " Jonathan Gray
2017-03-23 11:39 ` Emil Velikov
2 siblings, 1 reply; 94+ messages in thread
From: Rob Clark @ 2017-03-22 21:48 UTC (permalink / raw)
To: Dylan Baker; +Cc: mesa-dev, Maling list - DRI developers
On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
> Quoting Rob Clark (2017-03-22 10:07:54)
>> I guess an interesting question (from someone who doesn't know meson
>> yet) would be whether meson could slurp in the Makefile.sources type
>> stuff that we have, which are shared so far between
>> android/scons/autotools (and for the most part, kept developers from
>> having to care *too* much about the different build systems)
>
> Jason and I have talked about that too. I'd suggested that we could write a
> module for meson to read makefile.sources (since we're surely not the only
> project that would benefit from such a module), except that android is moving to
> blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't
> support using makefile.sources, so it seems somewhat moot in a world of
> blueprint for android, meson for *.
I guess even if it is only a temporary thing, something that could
slurp in Makefile.sources seems like it would be useful for a
transition period.
I'm not totally up to speed on android/blueprint stuff.. but even some
simplified or different "here-are-my-sources" type file that could be
shared across build systems would be useful. Meson sounds a bit more
extensible so maybe there is some potential to adapt to whatever
android forces on us ;-)
> I don't think that meson should try to generate blueprint files, since blueprint
> is itself a metabuild system that generates ninja files, and is self
> boot-strapping Go code. I don't know if the community is going to want blueprint
> to live in repo either, since one actually writes Go code for the build system.
> (I'm not objecting prematurely, I'm just pointing out that the design is
> significantly different the Android.mk, and the community will probably want to
> re-evaluate)
>
> If android doesn't mandate a migration to blueprint, or blueprint does handle
> makefile.sources (I don't think it does), I'd be happy to propose a module for
> meson that could read makefile.sources, and write said module, and get said
> module upstream.
I guess from my PoV with my developer hat on, as long as simple things
like adding/removing src files to an existing .so or .a require just
editing one build file for all build systems, that pretty much
guarantees that I don't forget to update one and anger
windows/android/$other_random_thing builders ;-)
(with my $enterprise_distro hat on, I think *probably* the main thing
is that we don't drop autotools build support before
gnome/gstreamer/etc.. not 100% sure about the py3 dependency but I
guess if we aren't the only one that needs it to build, that helps..)
BR,
-R
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 20:57 ` [Mesa-dev] " Dylan Baker
@ 2017-03-22 22:02 ` Rob Clark
2017-03-22 22:15 ` Eric Anholt
2017-03-24 14:03 ` Jose Fonseca
1 sibling, 1 reply; 94+ messages in thread
From: Rob Clark @ 2017-03-22 22:02 UTC (permalink / raw)
To: Dylan Baker
Cc: Jose Fonseca, Brian Paul, Emil Velikov, ML dri-devel,
Jason Ekstrand, ML mesa-dev
On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>
> Notably gnome is moving to meson (and some parts already use it), weston and
> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
> can't say for sure it's going to be around forever, but its been in development
> since late 2012 and still lands several patches a day, they were responsive to
> me when I sent a patch (that I still need to respin), and they seem to be
> picking up momentum from downstreams.
btw, possibly newbie question, but from what I can tell so far in
meson docs, there are separate 'meson build && cd build && ninja'
steps.. one nice thing about autotools is 'git pull && make' (and it
somehow magically figures out whether to re-automake/autoconf). Not
sure if there is a way to do something like that in meson.
(I nearly always use separate build and debug builddirs w/ autotools,
so that part I don't mind.. you can git-pull from a subdir fo the git
tree)
BR,
-R
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 22:02 ` Rob Clark
@ 2017-03-22 22:15 ` Eric Anholt
2017-03-22 22:33 ` Dylan Baker
0 siblings, 1 reply; 94+ messages in thread
From: Eric Anholt @ 2017-03-22 22:15 UTC (permalink / raw)
To: Rob Clark, Dylan Baker; +Cc: Emil Velikov, ML dri-devel, ML mesa-dev
[-- Attachment #1.1: Type: text/plain, Size: 1070 bytes --]
Rob Clark <robdclark@gmail.com> writes:
> On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
>> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>>
>> Notably gnome is moving to meson (and some parts already use it), weston and
>> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
>> can't say for sure it's going to be around forever, but its been in development
>> since late 2012 and still lands several patches a day, they were responsive to
>> me when I sent a patch (that I still need to respin), and they seem to be
>> picking up momentum from downstreams.
>
>
> btw, possibly newbie question, but from what I can tell so far in
> meson docs, there are separate 'meson build && cd build && ninja'
> steps.. one nice thing about autotools is 'git pull && make' (and it
> somehow magically figures out whether to re-automake/autoconf). Not
> sure if there is a way to do something like that in meson.
Consider meson build to be ./autogen.sh. After that point you can git
pull && make.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 16:40 ` Alex Deucher
2017-03-22 17:07 ` Rob Clark
@ 2017-03-22 22:30 ` Eric Anholt
1 sibling, 0 replies; 94+ messages in thread
From: Eric Anholt @ 2017-03-22 22:30 UTC (permalink / raw)
To: Alex Deucher, Dylan Baker; +Cc: mesa-dev, Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 4937 bytes --]
Alex Deucher <alexdeucher@gmail.com> writes:
> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
>> Why bother, and why would we want this? │~
>>
>> First it's written in python, which means the potential developer base
>> is massive. And it provides a recursive view for humans, but a
>> non-recursive view for the system. This is the best of both worlds,
>> humans can organize the build system in a way that makes sense, and the
>> machine gets a non-recursive build system. It also uses ninja rather
>> than make, and ninja is faster than make inherently. Meson is also a
>> simpler syntax than autotools or cmake it's not Turing Complete by
>> design nor does it expose python, again, by design. This allows meson
>> itself to be reimplemented in a another language if python becomes a
>> dead-end or a bottle-neck. It also makes it much easier to understand
>> what the build system is doing.
>>
>> What's different about using meson?
>>
>> Well, apart from a faster builds and less magic in the build system? The
>> configure flags are different, it uses -D<opt>=<value> more like cmake
>> than the --enable or --with flags of autotools, although oddly it uses
>> --prefix and friends when calling meson, but not with mesonconf, there's
>> a bug opened on this. Meson also doesn't support in-tree builds at all;
>> all builds are done out of tree. It also doesn't provide a "make dist"
>> target, fortunately there's this awesome tool called git, and it
>> provides a "git archive" command that does much the same thing. Did I
>> mention it's fast?
>>
>> Here are the performance numbers I see on a 2 core 4 thread SKL, without
>> initial configuration, and building out of tree (using zsh):
>>
>> For meson the command line is:
>> time (meson build -Dmanpages=true && ninja -C build)
>>
>> For autotools the command line is:
>> time (mdkir build && cd build && ../autotools && make -j5 -l4)<Paste>
>>
>> meson (cold ccache): 13.37s user 1.74s system 255% cpu 5.907 total
>> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
>> meson (hot ccache): 2.13s user 0.39s system 154% cpu 1.633 total
>> autotools (hot ccache): 13.93s user 0.73s system 102% cpu 14.259 total
>>
>> That's ~4x faster for a cold build and ~10x faster for a hot build.
>>
>> For a make clean && make style build with a hot cache:
>> meson: 4.64s user 0.33s system 334% cpu 1.486 total
>> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>>
>> Why bother with libdrm?
>>
>> It's a simple build system, that could be completely (or mostly
>> completely) be ported in a very short time, and could serve as a tech
>> demo for the advantages of using meson to garner feedback for embarking
>> on a larger project, like mesa (which is what I'm planning to work on
>> next).
>>
>> tl;dr
>>
>> I wrote this as practice for porting Mesa, and figured I might as well
>> send it out since I wrote it.
>>
>> It is very likely that neither of these large patches will show up on the
>> mailing list, but this is available at my github:
>> https://github.com/dcbaker/libdrm wip/meson
>
>
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson. It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve. While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers. autotools isn't great, but most people are familiar enough
> with it that they can get by. Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools. I'm not sure
> that would be the case for meson. Do we as a community feel we have
> enough meson experience to get people over the hump? Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.
Meson is so much nicer for the casual contributor than autoconf. I've
been hacking at converting the X Server for two days, and I'm now far
more capable at meson than have ever been at autotools, and I've been
doing autotools for 15 years (I don't know how many autotools build
systems I've written over that time, but it's in the tens at least).
I think meson is a win for new users already. I think we get into even
bigger wins when we consider the use of wrap when there's no distro copy
of a library -- just imagine never having to write instructions like the
"X Server" or "Mesa" parts of this page again:
https://github.com/anholt/mesa/wiki/VC4-complete-Raspbian-upgrade
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 22:15 ` Eric Anholt
@ 2017-03-22 22:33 ` Dylan Baker
0 siblings, 0 replies; 94+ messages in thread
From: Dylan Baker @ 2017-03-22 22:33 UTC (permalink / raw)
To: Eric Anholt, Rob Clark; +Cc: Emil Velikov, ML dri-devel, ML mesa-dev
[-- Attachment #1.1: Type: text/plain, Size: 1310 bytes --]
Quoting Eric Anholt (2017-03-22 15:15:46)
> Rob Clark <robdclark@gmail.com> writes:
>
> > On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
> >> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
> >>
> >> Notably gnome is moving to meson (and some parts already use it), weston and
> >> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
> >> can't say for sure it's going to be around forever, but its been in development
> >> since late 2012 and still lands several patches a day, they were responsive to
> >> me when I sent a patch (that I still need to respin), and they seem to be
> >> picking up momentum from downstreams.
> >
> >
> > btw, possibly newbie question, but from what I can tell so far in
> > meson docs, there are separate 'meson build && cd build && ninja'
> > steps.. one nice thing about autotools is 'git pull && make' (and it
> > somehow magically figures out whether to re-automake/autoconf). Not
> > sure if there is a way to do something like that in meson.
>
> Consider meson build to be ./autogen.sh. After that point you can git
> pull && make.
Additionally, ninja has the same -C flag as make. So that can be 'meson build &&
ninja -C build' and 'git pull && ninja -C build'
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljS+8gACgkQCJ4WlhQG
iO8gEgf6AzrODZtp+H+OjhLnh+etBN2N+E0TRuAba+IIG4Y3mdKueiY0AryJmlv+
Q6VdLMrcQ9k90kRxZoVARSu2w3mrTpPHLz2D/zkZTBoNPDKwl8ZtQbFyKsMaoi7X
+S78vkP6nqoiDvNRJ922tvqoGc7Wgo6YHCrM7liN6e3pf/OTabWTE4hPA6cubqfh
ALg5CW5FsFxVBDprkEVXQE36GldAbHpqrljHE7uUhiAK9Bwvwsjan41b++5kWv2p
6cYr1jtNR3/WqtDxgId5edsXl7Knqq0J2aei+I1BD6Vh6VlMhiGx8LTZUm7qZqvO
CU9TPJ4jnCAJ3si3lmFzuI6DDYX/YQ==
=LyvV
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 20:10 ` [Mesa-dev] " Dylan Baker
2017-03-22 21:48 ` Rob Clark
@ 2017-03-23 1:18 ` Jonathan Gray
2017-03-23 1:38 ` Rob Clark
2017-03-23 11:39 ` Emil Velikov
2 siblings, 1 reply; 94+ messages in thread
From: Jonathan Gray @ 2017-03-23 1:18 UTC (permalink / raw)
To: Dylan Baker; +Cc: mesa-dev, Maling list - DRI developers
On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> > I guess I'm a little late to the party here, but I haven't had time to
> > really let all of this sink in and actually look at meson. It doesn't
> > seem so bad with a quick look and I think I could probably sort it out
> > when the time came, but there would still be a bit of a learning
> > curve. While that may not be a big deal at the micro level, I have
> > concerns at the macro level.
> >
> > First, I'm concerned it may discourage casual developers and
> > packagers. autotools isn't great, but most people are familiar enough
> > with it that they can get by. Most people have enough knowledge of
> > autotools that they can pretty easily diagnose a configuration based
> > failure. There are a lot of resources for autotools. I'm not sure
> > that would be the case for meson. Do we as a community feel we have
> > enough meson experience to get people over the hump? Anything that
> > makes it harder for someone to try a new build or do a bisect is a big
> > problem in my opinion.
>
> One of the things that's prompted this on our side (I've talked this over with
> other people at Intel before starting), was that clearly we *don't* know
> autotools well enough to get it right. Emil almost always finds cases were we've
> done things *almost*, but not quite right.
>
> For my part, it took me about 3 or 4 days of reading through the docs and
> writing the libdrm port to get it right, and a lot of that is just the
> boilerplate of having ~8 drivers that all need basically the same logic.
>
> > Next, my bigger concern is for distro and casual packagers and people
> > that maintain large build systems with lots of existing custom
> > configurations. Changing from autotools would basically require many
> > of these existing tools and systems to be rewritten and then deal with
> > the debugging and fall out from that. The potential decreased build
> > time is a nice bonus, but frankly a lot of people/companies have years
> > of investment in existing tools.
>
> Sure, but we're also not the only ones investigating meson. Gnome is using it
> already, libepoxy is using it, gstreamer is using it. There are patches for
> weston (written by Daniel Stone) and libinput (written by Peter Hutterer), there
> are some other projects in the graphics sphere that people are working on. So
> even if we as a community decide that meson isn't for us, it's not going away.
It is worth pointing out that it is currently required by no component
of an x.org stack. In the case of libepoxy it was added by a new maintainer
on a new release and even then autoconf remains.
And as far as I can tell nothing in the entire OpenBSD ports tree
currently requires meson to build including gnome and gstreamer.
>
> Quoting Rob Clark (2017-03-22 10:07:54)
> > I guess an interesting question (from someone who doesn't know meson
> > yet) would be whether meson could slurp in the Makefile.sources type
> > stuff that we have, which are shared so far between
> > android/scons/autotools (and for the most part, kept developers from
> > having to care *too* much about the different build systems)
>
> Jason and I have talked about that too. I'd suggested that we could write a
> module for meson to read makefile.sources (since we're surely not the only
> project that would benefit from such a module), except that android is moving to
> blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't
> support using makefile.sources, so it seems somewhat moot in a world of
> blueprint for android, meson for *.
>
> I don't think that meson should try to generate blueprint files, since blueprint
> is itself a metabuild system that generates ninja files, and is self
> boot-strapping Go code. I don't know if the community is going to want blueprint
> to live in repo either, since one actually writes Go code for the build system.
> (I'm not objecting prematurely, I'm just pointing out that the design is
> significantly different the Android.mk, and the community will probably want to
> re-evaluate)
>
> If android doesn't mandate a migration to blueprint, or blueprint does handle
> makefile.sources (I don't think it does), I'd be happy to propose a module for
> meson that could read makefile.sources, and write said module, and get said
> module upstream.
>
> [1] https://godoc.org/github.com/google/blueprint
> >
> > If so, that makes it easier to coexist with existing build systems. I
> > don't think it would be a good idea to remove the autotools build
> > anytime soon.. that should be the last one removed, after meson has
> > replaced scons (and hopefully android?)
>
> I would imagine that if we did merge meson, we would make at the very least one
> release with meson and autotools (scons is VMWare's thing, they can migrate at
> their leisure), if not two, to give us a chance to flush out the bugs and to
> give various distros who don't have meson ready yet a chance. It'll also give
> the fast moving and aggressive distros like Arch and Fedora and chance to
> migrate and report bugs.
>
> Dylan
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-23 1:18 ` [Mesa-dev] " Jonathan Gray
@ 2017-03-23 1:38 ` Rob Clark
2017-03-24 13:42 ` Jose Fonseca
0 siblings, 1 reply; 94+ messages in thread
From: Rob Clark @ 2017-03-23 1:38 UTC (permalink / raw)
To: Jonathan Gray; +Cc: mesa-dev, Maling list - DRI developers
On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> > I guess I'm a little late to the party here, but I haven't had time to
>> > really let all of this sink in and actually look at meson. It doesn't
>> > seem so bad with a quick look and I think I could probably sort it out
>> > when the time came, but there would still be a bit of a learning
>> > curve. While that may not be a big deal at the micro level, I have
>> > concerns at the macro level.
>> >
>> > First, I'm concerned it may discourage casual developers and
>> > packagers. autotools isn't great, but most people are familiar enough
>> > with it that they can get by. Most people have enough knowledge of
>> > autotools that they can pretty easily diagnose a configuration based
>> > failure. There are a lot of resources for autotools. I'm not sure
>> > that would be the case for meson. Do we as a community feel we have
>> > enough meson experience to get people over the hump? Anything that
>> > makes it harder for someone to try a new build or do a bisect is a big
>> > problem in my opinion.
>>
>> One of the things that's prompted this on our side (I've talked this over with
>> other people at Intel before starting), was that clearly we *don't* know
>> autotools well enough to get it right. Emil almost always finds cases were we've
>> done things *almost*, but not quite right.
>>
>> For my part, it took me about 3 or 4 days of reading through the docs and
>> writing the libdrm port to get it right, and a lot of that is just the
>> boilerplate of having ~8 drivers that all need basically the same logic.
>>
>> > Next, my bigger concern is for distro and casual packagers and people
>> > that maintain large build systems with lots of existing custom
>> > configurations. Changing from autotools would basically require many
>> > of these existing tools and systems to be rewritten and then deal with
>> > the debugging and fall out from that. The potential decreased build
>> > time is a nice bonus, but frankly a lot of people/companies have years
>> > of investment in existing tools.
>>
>> Sure, but we're also not the only ones investigating meson. Gnome is using it
>> already, libepoxy is using it, gstreamer is using it. There are patches for
>> weston (written by Daniel Stone) and libinput (written by Peter Hutterer), there
>> are some other projects in the graphics sphere that people are working on. So
>> even if we as a community decide that meson isn't for us, it's not going away.
>
> It is worth pointing out that it is currently required by no component
> of an x.org stack. In the case of libepoxy it was added by a new maintainer
> on a new release and even then autoconf remains.
>
> And as far as I can tell nothing in the entire OpenBSD ports tree
> currently requires meson to build including gnome and gstreamer.
>
but I guess that is conflating two completely different topics..
addition of meson and removal of autotools. It is probably better
that we treat the topics separately. I don't see any way that the two
can happen at the same time.
The autotools build probably needs to remain for at least a couple
releases, and I certainly wouldn't mind if some of the other desktop
projects took the leap of dropping autotools first (at least then
various different "distro" consumers will have already dealt with how
to build meson packages)
None of that blocks addition of a meson build system (or what various
developers use day to day)
BR,
-R
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 21:05 ` Dylan Baker
@ 2017-03-23 8:13 ` Jani Nikula
0 siblings, 0 replies; 94+ messages in thread
From: Jani Nikula @ 2017-03-23 8:13 UTC (permalink / raw)
To: Dylan Baker, dri-devel; +Cc: mesa-dev
On Wed, 22 Mar 2017, Dylan Baker <dylan@pnwbakers.com> wrote:
> Quoting Jani Nikula (2017-03-22 01:24:19)
>> Right. That helps avoid many of the issues e.g. Sphinx has with the
>> configuration files being pure python.
>
> Yes, sphinx's configuration files are awful for just that reason.
Of course, for the exact same reason they are so flexible you can work
around all the problems. ;)
J.
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 20:10 ` [Mesa-dev] " Dylan Baker
2017-03-22 21:48 ` Rob Clark
2017-03-23 1:18 ` [Mesa-dev] " Jonathan Gray
@ 2017-03-23 11:39 ` Emil Velikov
2017-03-23 17:54 ` Dylan Baker
2017-03-25 1:06 ` Kenneth Graunke
2 siblings, 2 replies; 94+ messages in thread
From: Emil Velikov @ 2017-03-23 11:39 UTC (permalink / raw)
To: Dylan Baker; +Cc: mesa-dev, Maling list - DRI developers
On 22 March 2017 at 20:10, Dylan Baker <dylan@pnwbakers.com> wrote:
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> I guess I'm a little late to the party here, but I haven't had time to
>> really let all of this sink in and actually look at meson. It doesn't
>> seem so bad with a quick look and I think I could probably sort it out
>> when the time came, but there would still be a bit of a learning
>> curve. While that may not be a big deal at the micro level, I have
>> concerns at the macro level.
>>
>> First, I'm concerned it may discourage casual developers and
>> packagers. autotools isn't great, but most people are familiar enough
>> with it that they can get by. Most people have enough knowledge of
>> autotools that they can pretty easily diagnose a configuration based
>> failure. There are a lot of resources for autotools. I'm not sure
>> that would be the case for meson. Do we as a community feel we have
>> enough meson experience to get people over the hump? Anything that
>> makes it harder for someone to try a new build or do a bisect is a big
>> problem in my opinion.
>
> One of the things that's prompted this on our side (I've talked this over with
> other people at Intel before starting), was that clearly we *don't* know
> autotools well enough to get it right.
You do know that I'm always happy to answer questions and help people
;-) Just last night I gave a 2 minute crash course to Lyude why things
behave strange and how to get the desired workflow.
> Emil almost always finds cases were we've
> done things *almost*, but not quite right.
>
Care I say it - I'm a pessimist forged by unfortunate circumstances.
Hence I always see things that are wrong - Mesa build system is no
exception.
I'm fairly confident that if/when we move to Meson we (I?) will be
fixing bugs for at least two releases.
The more frustrating part is that atm autotools build is "bug-free"
and with meson will have to go through the same route again :-\
> For my part, it took me about 3 or 4 days of reading through the docs and
> writing the libdrm port to get it right, and a lot of that is just the
> boilerplate of having ~8 drivers that all need basically the same logic.
>
Slightly off-topic - 3 days to write the build script for ~10 [nearly]
identical libraries which do not do anything fancy, seems a lot.
Which was the most time consuming part ?
I'm concerned that we would have to enforce the same time penalty onto
dozens of developers unfamiliar with meson.
Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 5:00 ` Jonathan Gray
2017-03-21 16:00 ` Matt Turner
@ 2017-03-23 12:23 ` Jonathan Gray
2017-03-23 18:31 ` Emil Velikov
2 siblings, 0 replies; 94+ messages in thread
From: Jonathan Gray @ 2017-03-23 12:23 UTC (permalink / raw)
To: Timothy Arceri; +Cc: ML mesa-dev, Emil Velikov, ML dri-devel
On Tue, Mar 21, 2017 at 04:00:37PM +1100, Jonathan Gray wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
> >
> >
> > On 21/03/17 06:39, Emil Velikov wrote:
> > > On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
> > > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > > > > Seems like we ended up all over the place, so let me try afresh.
> > > > >
> > > > > Above all:
> > > > > - Saying "I don't care" about your users is arrogant - let us _not_
> > > > > do that, please ?
> > > >
> > > > Let's be honest, the OpenBSD is subjecting itself to some pretty
> > > > arbitrary restrictions caused including Mesa in its core: 10+ year old
> > > > GCC,
> > > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> > > wasn't OpenBSD to blame here ;-)
> >
> > Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
> > switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
> >
> > Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
> > rather not go through the upgrade hassle if I don't have to."
> >
> > Followed by Jose "We're internally building and shipping Mesa compiled with
> > GCC 4.4 (more specifically 4.4.3).
> >
> > It's fine if you require GCC 4.8 on automake, but please leave support
> > for GCC 4.4.x in SCons."
> >
> > By this point I got bored and moved on. But OpenBSDs GCC is a fork with
> > various features backported, from what I understand Mesa would not build on
> > a real GCC 4.2 release and we should not be using it as a min version. IMO
> > if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
> > the min GCC version.
> >
> > I believe Jonathan would like us to stick with 4.2 as min but is prepared to
> > deal with it if we move on.
>
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.
>
> We have one platform using clang/lld now (arm64) and are likely to move
> others in future where possible. libtool has to be patched and the Mesa
> configure script regenerated to make this work or Mesa won't build due
> to libtool.m4 looking for specific strings in ld -v produced by bfd
> binutils or gold...
>
> And yes if you change the configure script to check for a newer version
> I'll revert it locally like I did with the zlib one.
>
> As I get the impression no one cares about patches for older GCC I've
> not being sending them to the list, ie
And to be clear this is code in Mesa violating the C++ standard
according to clang++ --std=c++14 -pedantic.
compiler/brw_vec4_gs_visitor.cpp:589:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_POINTS] =_3DPRIM_POINTLIST,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:590:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_LINES] = _3DPRIM_LINELIST,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:591:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_LINE_LOOP] = _3DPRIM_LINELOOP,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:592:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_LINE_STRIP] = _3DPRIM_LINESTRIP,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:593:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_TRIANGLES] = _3DPRIM_TRILIST,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:594:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_TRIANGLE_STRIP] = _3DPRIM_TRISTRIP,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:595:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_TRIANGLE_FAN] = _3DPRIM_TRIFAN,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:596:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_QUADS] = _3DPRIM_QUADLIST,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:597:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_QUAD_STRIP] = _3DPRIM_QUADSTRIP,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:598:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_POLYGON] = _3DPRIM_POLYGON,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:599:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_LINES_ADJACENCY] = _3DPRIM_LINELIST_ADJ,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:600:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_LINE_STRIP_ADJACENCY] = _3DPRIM_LINESTRIP_ADJ,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:601:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_TRIANGLES_ADJACENCY] = _3DPRIM_TRILIST_ADJ,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler/brw_vec4_gs_visitor.cpp:602:4: warning: designated initializers are a C99 feature [-Wc99-extensions]
[GL_TRIANGLE_STRIP_ADJACENCY] = _3DPRIM_TRISTRIP_ADJ,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-23 11:39 ` Emil Velikov
@ 2017-03-23 17:54 ` Dylan Baker
2017-03-25 1:06 ` Kenneth Graunke
1 sibling, 0 replies; 94+ messages in thread
From: Dylan Baker @ 2017-03-23 17:54 UTC (permalink / raw)
To: Emil Velikov; +Cc: mesa-dev, Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 1966 bytes --]
Quoting Emil Velikov (2017-03-23 04:39:50)
> On 22 March 2017 at 20:10, Dylan Baker <dylan@pnwbakers.com> wrote:
>
> The more frustrating part is that atm autotools build is "bug-free"
> and with meson will have to go through the same route again :-\
Sure, but if it's easier to get right (which I'm asserting it is), then meson
should pay off in the long run by needing less maintenance to remain "bug-free",
since fewer bugs will be introduced.
> Slightly off-topic - 3 days to write the build script for ~10 [nearly]
> identical libraries which do not do anything fancy, seems a lot.
> Which was the most time consuming part ?
Mostly talking with Matt about which patterns from autotools don't make sense to
port to meson. Also in those 3-4 days were a stab at mesa that made me realize
it was too big a of project for the first go, and picking a smaller, simpler
first project made sense. Honestly the about half of that time was spent reading
autotools documentation to figure out what some of the macros did, and then
reading meson bugs to figure out what the meson equivalent is. I have
familiarity with cmake, but this was the first major work with autotools I've
done. At this point working on Mesa the meson is just coming and I spend a lot
more time reading autotools documentation and asking Matt "What does X do, and
does it have side effects?"
>
> I'm concerned that we would have to enforce the same time penalty onto
> dozens of developers unfamiliar with meson.
Eric (who as done a lot more autotools than me) said it took him 2 days to
become a more comfortable with meson than autotools, having written autotools
for 10 years. Asking Eric, Daniel Stone, or Peter Hutterer, who all have much
more autotools experience than me, would probably be more useful to answer that
question. I can say this, it took me significantly less time to become fluent
with meson than to become passable with cmake.
Dylan
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljUC80ACgkQCJ4WlhQG
iO/VwAf6Arp0teNz0tA1JkYRaUtMien+Puiti7cSt7qGcyU5dsh3Lz5vQkdpfmq7
3716mlBwiCvYumnL5QvS9z7qOfbQn8qtRAQcEHyJsgtRALVaLr8Bz1D0/VLEizTo
O7/YaIW791EMrUj5mm4PIL5EAmwYyTrREHPgiyfErxisQv3g2+GnzmDMUm3OFYfh
IkfzvoKiK4Be3EGsZAWxTVe/xAcCFeL7PGToBhCvcKwfrvRUvWWG8/A9OKqVZ6YT
k4YC+0mdNIyBdbZuyk3Iks4CwK/kUH6Faj+dcSrKXEIDJ2tnkHbWeZgxY21fIy0o
zzuVIIV/7ay3wayWUZzXPs2Jc9v4rA==
=LBnr
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 5:00 ` Jonathan Gray
2017-03-21 16:00 ` Matt Turner
2017-03-23 12:23 ` Jonathan Gray
@ 2017-03-23 18:31 ` Emil Velikov
2 siblings, 0 replies; 94+ messages in thread
From: Emil Velikov @ 2017-03-23 18:31 UTC (permalink / raw)
To: Jonathan Gray; +Cc: ML mesa-dev, Timothy Arceri, ML dri-devel
On 21 March 2017 at 05:00, Jonathan Gray <jsg@jsg.id.au> wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> > > > Seems like we ended up all over the place, so let me try afresh.
>> > > >
>> > > > Above all:
>> > > > - Saying "I don't care" about your users is arrogant - let us _not_
>> > > > do that, please ?
>> > >
>> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
>> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
>> > > GCC,
>> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> > wasn't OpenBSD to blame here ;-)
>>
>> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
>> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
>>
>> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
>> rather not go through the upgrade hassle if I don't have to."
>>
>> Followed by Jose "We're internally building and shipping Mesa compiled with
>> GCC 4.4 (more specifically 4.4.3).
>>
>> It's fine if you require GCC 4.8 on automake, but please leave support
>> for GCC 4.4.x in SCons."
>>
>> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
>> various features backported, from what I understand Mesa would not build on
>> a real GCC 4.2 release and we should not be using it as a min version. IMO
>> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
>> the min GCC version.
>>
>> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
>> deal with it if we move on.
>
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.
>
> We have one platform using clang/lld now (arm64) and are likely to move
> others in future where possible. libtool has to be patched and the Mesa
> configure script regenerated to make this work or Mesa won't build due
> to libtool.m4 looking for specific strings in ld -v produced by bfd
> binutils or gold...
>
> And yes if you change the configure script to check for a newer version
> I'll revert it locally like I did with the zlib one.
>
> As I get the impression no one cares about patches for older GCC I've
> not being sending them to the list, ie
>
> commit d3d340d6026e516cc405a2eb1d925a7a7a467480
> Author: Jonathan Gray <jsg@jsg.id.au>
> Date: Thu Mar 16 00:30:07 2017 +1100
>
> i965: don't use designated array initialisation
>
> Don't use a form of designated array initialisation that breaks gcc 4.2.1.
>
Jonathan, I think you meant to say:
Using C99 designated initializers is not allowed in C++ code, thus the
compiler may warn or even fail.
>
> Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
>
> diff --git a/src/intel/compiler/brw_vec4_gs_visitor.cpp b/src/intel/compiler/brw_vec4_gs_visitor.cpp
> index 4a8b5be30e..e7a502306e 100644
> --- a/src/intel/compiler/brw_vec4_gs_visitor.cpp
> +++ b/src/intel/compiler/brw_vec4_gs_visitor.cpp
> @@ -585,23 +585,6 @@ vec4_gs_visitor::gs_end_primitive()
> emit(OR(dst_reg(this->control_data_bits), this->control_data_bits, mask));
> }
>
> -static const GLuint gl_prim_to_hw_prim[GL_TRIANGLE_STRIP_ADJACENCY+1] = {
We already have C helper get_hw_prim_for_gl_prim that we can use instead.
I'll send a patch in a minute.
Thanks
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 21:48 ` Rob Clark
@ 2017-03-23 21:56 ` Greg Hackmann
2017-03-23 22:14 ` Colin Cross
0 siblings, 1 reply; 94+ messages in thread
From: Greg Hackmann @ 2017-03-23 21:56 UTC (permalink / raw)
To: Rob Clark, Dylan Baker; +Cc: mesa-dev, Maling list - DRI developers, ccross
On 03/22/2017 02:48 PM, Rob Clark wrote:
> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
>> Quoting Rob Clark (2017-03-22 10:07:54)
>>> I guess an interesting question (from someone who doesn't know meson
>>> yet) would be whether meson could slurp in the Makefile.sources type
>>> stuff that we have, which are shared so far between
>>> android/scons/autotools (and for the most part, kept developers from
>>> having to care *too* much about the different build systems)
>>
>> Jason and I have talked about that too. I'd suggested that we could write a
>> module for meson to read makefile.sources (since we're surely not the only
>> project that would benefit from such a module), except that android is moving to
>> blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't
>> support using makefile.sources, so it seems somewhat moot in a world of
>> blueprint for android, meson for *.
>
> I guess even if it is only a temporary thing, something that could
> slurp in Makefile.sources seems like it would be useful for a
> transition period.
>
> I'm not totally up to speed on android/blueprint stuff.. but even some
> simplified or different "here-are-my-sources" type file that could be
> shared across build systems would be useful. Meson sounds a bit more
> extensible so maybe there is some potential to adapt to whatever
> android forces on us ;-)
+ccross from the Android build team can hopefully provide some input here.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-23 21:56 ` Greg Hackmann
@ 2017-03-23 22:14 ` Colin Cross
2017-03-23 23:56 ` Dylan Baker
0 siblings, 1 reply; 94+ messages in thread
From: Colin Cross @ 2017-03-23 22:14 UTC (permalink / raw)
To: Greg Hackmann; +Cc: mesa-dev, Maling list - DRI developers, Dylan Baker
On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann <ghackmann@google.com> wrote:
> On 03/22/2017 02:48 PM, Rob Clark wrote:
>>
>> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
>>>
>>> Quoting Rob Clark (2017-03-22 10:07:54)
>>>>
>>>> I guess an interesting question (from someone who doesn't know meson
>>>> yet) would be whether meson could slurp in the Makefile.sources type
>>>> stuff that we have, which are shared so far between
>>>> android/scons/autotools (and for the most part, kept developers from
>>>> having to care *too* much about the different build systems)
>>>
>>>
>>> Jason and I have talked about that too. I'd suggested that we could write
>>> a
>>> module for meson to read makefile.sources (since we're surely not the
>>> only
>>> project that would benefit from such a module), except that android is
>>> moving to
>>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
>>> doesn't
>>> support using makefile.sources, so it seems somewhat moot in a world of
>>> blueprint for android, meson for *.
>>
>>
>> I guess even if it is only a temporary thing, something that could
>> slurp in Makefile.sources seems like it would be useful for a
>> transition period.
>>
>> I'm not totally up to speed on android/blueprint stuff.. but even some
>> simplified or different "here-are-my-sources" type file that could be
>> shared across build systems would be useful. Meson sounds a bit more
>> extensible so maybe there is some potential to adapt to whatever
>> android forces on us ;-)
>
>
> +ccross from the Android build team can hopefully provide some input here.
For cases like this, we generally add a python script that translates
the build files into something Blueprint understands, and rerun it
each time we import into the project.
Alternatively, Blueprint efficiently supports globbing for sources, so
if all the source files are always listed in Makefile.sources (which
seems to be true in our copy of libdrm except for intel/test_decode.c)
then we could use globs and ignore the makefiles, possibly manually
excluding a few files.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-23 22:14 ` Colin Cross
@ 2017-03-23 23:56 ` Dylan Baker
2017-03-24 0:03 ` [Mesa-dev] " Colin Cross
0 siblings, 1 reply; 94+ messages in thread
From: Dylan Baker @ 2017-03-23 23:56 UTC (permalink / raw)
To: Colin Cross, Greg Hackmann; +Cc: mesa-dev, Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 2581 bytes --]
Quoting Colin Cross (2017-03-23 15:14:16)
> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann <ghackmann@google.com> wrote:
> > On 03/22/2017 02:48 PM, Rob Clark wrote:
> >>
> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
> >>>
> >>> Quoting Rob Clark (2017-03-22 10:07:54)
> >>>>
> >>>> I guess an interesting question (from someone who doesn't know meson
> >>>> yet) would be whether meson could slurp in the Makefile.sources type
> >>>> stuff that we have, which are shared so far between
> >>>> android/scons/autotools (and for the most part, kept developers from
> >>>> having to care *too* much about the different build systems)
> >>>
> >>>
> >>> Jason and I have talked about that too. I'd suggested that we could write
> >>> a
> >>> module for meson to read makefile.sources (since we're surely not the
> >>> only
> >>> project that would benefit from such a module), except that android is
> >>> moving to
> >>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
> >>> doesn't
> >>> support using makefile.sources, so it seems somewhat moot in a world of
> >>> blueprint for android, meson for *.
> >>
> >>
> >> I guess even if it is only a temporary thing, something that could
> >> slurp in Makefile.sources seems like it would be useful for a
> >> transition period.
> >>
> >> I'm not totally up to speed on android/blueprint stuff.. but even some
> >> simplified or different "here-are-my-sources" type file that could be
> >> shared across build systems would be useful. Meson sounds a bit more
> >> extensible so maybe there is some potential to adapt to whatever
> >> android forces on us ;-)
> >
> >
> > +ccross from the Android build team can hopefully provide some input here.
>
> For cases like this, we generally add a python script that translates
> the build files into something Blueprint understands, and rerun it
> each time we import into the project.
>
> Alternatively, Blueprint efficiently supports globbing for sources, so
> if all the source files are always listed in Makefile.sources (which
> seems to be true in our copy of libdrm except for intel/test_decode.c)
> then we could use globs and ignore the makefiles, possibly manually
> excluding a few files.
I'm hoping you can clarify a couple of questions I have about blueprint:
1) android is moving to blueprint from android.mk files?
2) is there a publicly available project that uses blueprint I could look at?
The documentation I've been able to find is pretty sparse.
Dylan
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljUYJkACgkQCJ4WlhQG
iO/lWQf/UUJp2AZDZLfye248/XNNZPzNNAxF+SvoNx5SSAE3rZ9FT2eDbAiQRpog
GD1yjvdgN7HD0J7Y1dD3Kz5eReYEmVoWKu9kvhHaLU5Ijg+fe1ynt461QDt8kdR2
guhbYXoiwTCxGGCzKJ9Ns7LzHalUBR5baMfD+Lgvin2kB/G0VkACgS0hSTT8t13G
mNuKtgLGJinoTJsvt2AbKICzqwOXSODFq6zNIRkmFsJFUu/SM2gN+M+A4jVvwVCd
l7RQNyx9GDxEEft/I013aVG6Px7JBTEZ1jMAWLvnwYH14NWaicvhm3uKaPB5+t1j
TOixhRaQeNWpVBdE/yB70lyjT4/82w==
=KyH7
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-23 23:56 ` Dylan Baker
@ 2017-03-24 0:03 ` Colin Cross
2017-03-24 16:54 ` Dylan Baker
0 siblings, 1 reply; 94+ messages in thread
From: Colin Cross @ 2017-03-24 0:03 UTC (permalink / raw)
To: Dylan Baker; +Cc: mesa-dev, Maling list - DRI developers
On Thu, Mar 23, 2017 at 4:56 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
> Quoting Colin Cross (2017-03-23 15:14:16)
>> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann <ghackmann@google.com> wrote:
>> > On 03/22/2017 02:48 PM, Rob Clark wrote:
>> >>
>> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
>> >>>
>> >>> Quoting Rob Clark (2017-03-22 10:07:54)
>> >>>>
>> >>>> I guess an interesting question (from someone who doesn't know meson
>> >>>> yet) would be whether meson could slurp in the Makefile.sources type
>> >>>> stuff that we have, which are shared so far between
>> >>>> android/scons/autotools (and for the most part, kept developers from
>> >>>> having to care *too* much about the different build systems)
>> >>>
>> >>>
>> >>> Jason and I have talked about that too. I'd suggested that we could write
>> >>> a
>> >>> module for meson to read makefile.sources (since we're surely not the
>> >>> only
>> >>> project that would benefit from such a module), except that android is
>> >>> moving to
>> >>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
>> >>> doesn't
>> >>> support using makefile.sources, so it seems somewhat moot in a world of
>> >>> blueprint for android, meson for *.
>> >>
>> >>
>> >> I guess even if it is only a temporary thing, something that could
>> >> slurp in Makefile.sources seems like it would be useful for a
>> >> transition period.
>> >>
>> >> I'm not totally up to speed on android/blueprint stuff.. but even some
>> >> simplified or different "here-are-my-sources" type file that could be
>> >> shared across build systems would be useful. Meson sounds a bit more
>> >> extensible so maybe there is some potential to adapt to whatever
>> >> android forces on us ;-)
>> >
>> >
>> > +ccross from the Android build team can hopefully provide some input here.
>>
>> For cases like this, we generally add a python script that translates
>> the build files into something Blueprint understands, and rerun it
>> each time we import into the project.
>>
>> Alternatively, Blueprint efficiently supports globbing for sources, so
>> if all the source files are always listed in Makefile.sources (which
>> seems to be true in our copy of libdrm except for intel/test_decode.c)
>> then we could use globs and ignore the makefiles, possibly manually
>> excluding a few files.
>
> I'm hoping you can clarify a couple of questions I have about blueprint:
> 1) android is moving to blueprint from android.mk files?
Yes, in a phased transition. We support both for now.
> 2) is there a publicly available project that uses blueprint I could look at?
> The documentation I've been able to find is pretty sparse.
Blueprint is a framework for writing build systems, and Soong is
AOSP's Blueprint build system. See
https://android.googlesource.com/platform/build/soong/+/master/README.md
for documentation on Soong.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-23 1:38 ` Rob Clark
@ 2017-03-24 13:42 ` Jose Fonseca
2017-03-24 17:13 ` Dylan Baker
2017-03-24 19:10 ` Kristian Høgsberg
0 siblings, 2 replies; 94+ messages in thread
From: Jose Fonseca @ 2017-03-24 13:42 UTC (permalink / raw)
To: Rob Clark, Jonathan Gray; +Cc: mesa-dev, Maling list - DRI developers
On 23/03/17 01:38, Rob Clark wrote:
> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>> I guess I'm a little late to the party here, but I haven't had time to
>>>> really let all of this sink in and actually look at meson. It doesn't
>>>> seem so bad with a quick look and I think I could probably sort it out
>>>> when the time came, but there would still be a bit of a learning
>>>> curve. While that may not be a big deal at the micro level, I have
>>>> concerns at the macro level.
>>>>
>>>> First, I'm concerned it may discourage casual developers and
>>>> packagers. autotools isn't great, but most people are familiar enough
>>>> with it that they can get by. Most people have enough knowledge of
>>>> autotools that they can pretty easily diagnose a configuration based
>>>> failure. There are a lot of resources for autotools. I'm not sure
>>>> that would be the case for meson. Do we as a community feel we have
>>>> enough meson experience to get people over the hump? Anything that
>>>> makes it harder for someone to try a new build or do a bisect is a big
>>>> problem in my opinion.
>>>
>>> One of the things that's prompted this on our side (I've talked this over with
>>> other people at Intel before starting), was that clearly we *don't* know
>>> autotools well enough to get it right. Emil almost always finds cases were we've
>>> done things *almost*, but not quite right.
>>>
>>> For my part, it took me about 3 or 4 days of reading through the docs and
>>> writing the libdrm port to get it right, and a lot of that is just the
>>> boilerplate of having ~8 drivers that all need basically the same logic.
>>>
>>>> Next, my bigger concern is for distro and casual packagers and people
>>>> that maintain large build systems with lots of existing custom
>>>> configurations. Changing from autotools would basically require many
>>>> of these existing tools and systems to be rewritten and then deal with
>>>> the debugging and fall out from that. The potential decreased build
>>>> time is a nice bonus, but frankly a lot of people/companies have years
>>>> of investment in existing tools.
>>>
>>> Sure, but we're also not the only ones investigating meson. Gnome is using it
>>> already, libepoxy is using it, gstreamer is using it. There are patches for
>>> weston (written by Daniel Stone) and libinput (written by Peter Hutterer), there
>>> are some other projects in the graphics sphere that people are working on. So
>>> even if we as a community decide that meson isn't for us, it's not going away.
>>
>> It is worth pointing out that it is currently required by no component
>> of an x.org stack. In the case of libepoxy it was added by a new maintainer
>> on a new release and even then autoconf remains.
>>
>> And as far as I can tell nothing in the entire OpenBSD ports tree
>> currently requires meson to build including gnome and gstreamer.
>>
>
> but I guess that is conflating two completely different topics..
> addition of meson and removal of autotools. It is probably better
> that we treat the topics separately. I don't see any way that the two
> can happen at the same time.
>
> The autotools build probably needs to remain for at least a couple
> releases, and I certainly wouldn't mind if some of the other desktop
> projects took the leap of dropping autotools first (at least then
> various different "distro" consumers will have already dealt with how
> to build meson packages)
>
> None of that blocks addition of a meson build system (or what various
> developers use day to day)
>
> BR,
> -R
I tend to disagree. While we can't avoid a transitory period, when we
embark on another build system (Meson or something else) I think we
should aim at 1) ensure such tool can indeed _completely_ replace at
least _one_ existing build system, 2) and aim at migration quickly.
Otherwise we'll just end up with yet another build system, yet another
way builds can fail, with some developers stuck on old build systems
because it works, or because the new build system quite doesn't work.
And this is from (painful) experience.
So I think we should identify stake holders soon, collect requirements
(OSes platforms, etc), make sure the prospective tool meets them, have
all stakeholders collaborate on a prototype, them embark on mass migration.
That is, if this fails, let it fail early. If it succeeds, may it
succeed early. Anything but a slow death / zombie life.
BTW, how about migrating mesademos to Meson? It currently has autotools
and cmake. I was hoping that cmake would replace autotools, but I
couldn't run fast enough, so I couldn't practice what preached above,
hence cmake doing almost but not all what autotools does.
And is not a crucial project for Linux distros -- few distros package it
-- and even if they do, no other package would depend on it. And is one
of those sort of projects that should be easy to port to any build too.
Even if we ignore everything else, just replacing autotools + cmake with
just one thing would be a net win.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-22 20:57 ` [Mesa-dev] " Dylan Baker
2017-03-22 22:02 ` Rob Clark
@ 2017-03-24 14:03 ` Jose Fonseca
2017-03-24 14:22 ` [Mesa-dev] " Daniel Stone
2017-03-24 16:23 ` Bas Nieuwenhuizen
1 sibling, 2 replies; 94+ messages in thread
From: Jose Fonseca @ 2017-03-24 14:03 UTC (permalink / raw)
To: Dylan Baker; +Cc: ML mesa-dev, ML dri-devel
On 22/03/17 20:57, Dylan Baker wrote:
> Quoting Jose Fonseca (2017-03-22 10:59:10)
>> On 17/03/17 02:28, Brian Paul wrote:
>>>
>>> [snip]
>>>
>>> Sure, I'd like to see one build system instead of two. Meson supports
>>> Windows so that's good. But the big issue is our automated build
>>> system. Replacing SCons with Meson could be a big deal in that
>>> context. It would at least involve pulling Meson into our toolchain and
>>> rewriting a bunch of Python code to grok Meson. I'd have to go off and
>>> investigate that to even see if it's a possibility. Maybe next week.
>>
>>
>> I don't have any experience with Meson. But for the record I don't have
>> much love for SCons. I long stopped using SCons for anything but Mesa.
>>
>> And my have good experience with cmake + ninja/msvc is positive. So
>> tools with similar architecture sound good overall.
>>
>> In fact, knowing what I know now, if I could go back in time, to when I
>> evaluated CMake and SCons, I'd chose CMake.
>>
>>
>> BTW, it seems that newer SCons will drop Python 2 support [1], which
>> might force us to rewrite a lot of SConsfiles/scripts any way. So
>> perhaps that's a good time to evaluate migrating to something else.
>>
>>
>>
>> That said, moving to another build system is always a herculian task.
>> Thought the benefit of having a single build system is appealing and
>> might save time down the line.
>>
>>
>>
>> But there are many questions I have about Meson: how confident are we
>> on Meson? Are big projects using it? How sure are we that it won't
>> become abandonware in a few years time? How does it compare with other
>> newer gen build systems?
>>
>
> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>
> Notably gnome is moving to meson (and some parts already use it), weston and
> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
> can't say for sure it's going to be around forever, but its been in development
> since late 2012 and still lands several patches a day, they were responsive to
> me when I sent a patch (that I still need to respin), and they seem to be
> picking up momentum from downstreams.
>
> As to how it compares to other build systems, it's fairly different than cmake
> and scons, it's much less scripting and much more declarative, you can look at
> the libdrm patch or the meson in libepoxy (which is more mature) to see the
> syntax. It doesn't expose python or a full scripting language, though it does
> have some fairly simple logic like if/elif/else and foreach, and they support
> modules that add functionality, but need to be merged upstream, this is how
> pkgconfig writing is implemented, for example. One of the things that it does
> better than autotools and (IMHO) cmake, is dependency management, in most cases
> it requires no special handling, the only case it does in mesa (so far) is for
> local python module dependencies in generators. I think that these are actually
> strengths of meson, it's simplicity makes it easy to understand and use.
>
> For support, it's written in pure python (using only the stdlib with no
> external deps), and requires python 3.4+. It has backends for ninja on Linux,
> ninja and visual studio on Windows, and xcode on macOS; Clang, GCC, and MSVC
> are considered first class compilers, some others might work, but are
> unsupported.
>
> I have a partial port of piglit to meson that I put together to see what
> porting from cmake to meson was like (with no plans to send to the list), I can
> push that somewhere for you to look at if you want to see the difference.
>
>>
>> We also have special requirements: one is cross-build from Linux to
>> MinGW, which on Mesa case requires building portions of the tree twice
>> -- once for host -- another for cross-mingw.
>
> Cross compiling for mingw is supported, and it provides a way to differentiate
> the build, host, and target machines [1], I've cross compiled for
> aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag for
> this, but the meson approach is to write an ini file once, and use it again and
> again), and the first example of cross compiling is using mingw from linux [2].
>
> [1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
> [2]https://github.com/mesonbuild/meson/wiki/Cross-compilation
Thanks for the info.
It still scares me a bit that most Meson users are mostly Linux focused.
Another tool I heard good about but have not direct experience is
https://bazel.build . Any thoughts about it?
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 14:03 ` Jose Fonseca
@ 2017-03-24 14:22 ` Daniel Stone
2017-03-24 15:47 ` Jose Fonseca
2017-03-24 16:23 ` Bas Nieuwenhuizen
1 sibling, 1 reply; 94+ messages in thread
From: Daniel Stone @ 2017-03-24 14:22 UTC (permalink / raw)
To: Jose Fonseca; +Cc: ML mesa-dev, ML dri-devel, Dylan Baker
Hi Jose,
On 24 March 2017 at 14:03, Jose Fonseca <jfonseca@vmware.com> wrote:
> On 22/03/17 20:57, Dylan Baker wrote:
>> Cross compiling for mingw is supported, and it provides a way to
>> differentiate
>> the build, host, and target machines [1], I've cross compiled for
>> aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag
>> for
>> this, but the meson approach is to write an ini file once, and use it
>> again and
>> again), and the first example of cross compiling is using mingw from linux
>> [2].
>>
>>
>> [1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
>> [2]https://github.com/mesonbuild/meson/wiki/Cross-compilation
>
>
> Thanks for the info.
>
> It still scares me a bit that most Meson users are mostly Linux focused.
That's not actually true ...
A lot of the reason GStreamer went towards Meson is because it has
native OS X (XCode project) and Windows (MinGW or Visual Studio
project) support. Meson's own source tree goes out of its way to use
spaces in directory and file names for its test suite, to make sure
that that support never breaks. Every build of Meson is CI'd on
AppVeyor as well as Travis for OS X. And of course, the GStreamer CI
uses Meson for its non-Linux builds.
It's true that a lot of the projects taking an interest of late have
been Linux, yes. But if you're native to Windows / OS X, you just use
VS/Xcode. There are (IMO) very few properly cross-platform projects
who are 'Windows projects with a port' or 'mainly OS X but also runs
on Linux', rather than cross-platform 'Linux projects'.
> Another tool I heard good about but have not direct experience is
> https://bazel.build . Any thoughts about it?
If you look at the FAQ, one of the first things you'll see is that
they don't properly support Windows. It also requires Java to run,
which I'd say would be a no-go if people are already complaining about
the impossibility of installing several megabytes of Python stdlib.
Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 14:22 ` [Mesa-dev] " Daniel Stone
@ 2017-03-24 15:47 ` Jose Fonseca
2017-03-25 20:15 ` [Mesa-dev] " Rob Clark
0 siblings, 1 reply; 94+ messages in thread
From: Jose Fonseca @ 2017-03-24 15:47 UTC (permalink / raw)
To: Daniel Stone; +Cc: ML mesa-dev, ML dri-devel
On 24/03/17 14:22, Daniel Stone wrote:
> Hi Jose,
>
> On 24 March 2017 at 14:03, Jose Fonseca <jfonseca@vmware.com> wrote:
>> On 22/03/17 20:57, Dylan Baker wrote:
>>> Cross compiling for mingw is supported, and it provides a way to
>>> differentiate
>>> the build, host, and target machines [1], I've cross compiled for
>>> aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag
>>> for
>>> this, but the meson approach is to write an ini file once, and use it
>>> again and
>>> again), and the first example of cross compiling is using mingw from linux
>>> [2].
>>>
>>>
>>> [1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
>>> [2]https://github.com/mesonbuild/meson/wiki/Cross-compilation
>>
>>
>> Thanks for the info.
>>
>> It still scares me a bit that most Meson users are mostly Linux focused.
>
> That's not actually true ...
>
> A lot of the reason GStreamer went towards Meson is because it has
> native OS X (XCode project) and Windows (MinGW or Visual Studio
> project) support. Meson's own source tree goes out of its way to use
> spaces in directory and file names for its test suite, to make sure
> that that support never breaks. Every build of Meson is CI'd on
> AppVeyor as well as Travis for OS X. And of course, the GStreamer CI
> uses Meson for its non-Linux builds.
>
> It's true that a lot of the projects taking an interest of late have
> been Linux, yes. But if you're native to Windows / OS X, you just use
> VS/Xcode. There are (IMO) very few properly cross-platform projects
> who are 'Windows projects with a port' or 'mainly OS X but also runs
> on Linux', rather than cross-platform 'Linux projects'.
OK.
>> Another tool I heard good about but have not direct experience is
>> https://bazel.build . Any thoughts about it?
>
> If you look at the FAQ, one of the first things you'll see is that
> they don't properly support Windows. It also requires Java to run,
> which I'd say would be a no-go if people are already complaining about
> the impossibility of installing several megabytes of Python stdlib.
I see. Indeed.
Thanks. From the label on the tin, it does sound like Meson ticks a lot
of boxes then.
Like I said in another email, maybe mesademos is a good way to get our
feet wet.
I can't guarantee I'll be able to dedicate much time, but at least get
AppVeyor builds of it, since it has been a long objective of mine to get
mesademos/piglit/etc builds on AppVeyor instead of a private Jenkins server.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 14:03 ` Jose Fonseca
2017-03-24 14:22 ` [Mesa-dev] " Daniel Stone
@ 2017-03-24 16:23 ` Bas Nieuwenhuizen
1 sibling, 0 replies; 94+ messages in thread
From: Bas Nieuwenhuizen @ 2017-03-24 16:23 UTC (permalink / raw)
To: Jose Fonseca; +Cc: ML mesa-dev, ML dri-devel, Dylan Baker
> Another tool I heard good about but have not direct experience is
> https://bazel.build . Any thoughts about it?
Having looked a bit into it, it also is just a build system (albeit
higher level than ninja or make). It doesn't do configure or install
and working with system dependencies is annoying. While it is awesome
at some stuff, I think for these reasons mesa just is not a good
usecase for it.
- Bas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 0:03 ` [Mesa-dev] " Colin Cross
@ 2017-03-24 16:54 ` Dylan Baker
0 siblings, 0 replies; 94+ messages in thread
From: Dylan Baker @ 2017-03-24 16:54 UTC (permalink / raw)
To: Colin Cross; +Cc: mesa-dev, Maling list - DRI developers, Greg Hackmann
[-- Attachment #1.1: Type: text/plain, Size: 742 bytes --]
Quoting Colin Cross (2017-03-23 17:03:58)
> On Thu, Mar 23, 2017 at 4:56 PM, Dylan Baker <dylan@pnwbakers.com> wrote:
> >
> > I'm hoping you can clarify a couple of questions I have about blueprint:
> > 1) android is moving to blueprint from android.mk files?
>
> Yes, in a phased transition. We support both for now.
>
> > 2) is there a publicly available project that uses blueprint I could look at?
> > The documentation I've been able to find is pretty sparse.
>
> Blueprint is a framework for writing build systems, and Soong is
> AOSP's Blueprint build system. See
> https://android.googlesource.com/platform/build/soong/+/master/README.md
> for documentation on Soong.
Thanks, that's very useful information.
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljVT0sACgkQCJ4WlhQG
iO8oDwf9EEbINus3k0HGDo/QrZr0F6tdy10GFkW/r/+3Q38+zNzwCxw6v4ctHH5D
8MAqIj8aJSuUsWqmpfHTA2m9RtgQPXT630Q07qY/DFBb98jYfvdUpRzBoLU9uIPY
PK2MA2cBoVfBJRYoo8Y0yg5P4xV+5CT6XEHo49T+roHc9pHxYRF6bTlwAI0mFa3B
BANhqMBo6uebneVFedpaAspIvFFepnjuNJYeZBhxIQLxMs+65VgbB50wnUIt8UpT
yHlqpAffbvV+Tt8ld+b5Hms9INHSKV4Qbe79hLhOg27XvPCKaNmhoJGDM3CsCXk0
KGvYCRhT2qTXwa7XdvPFsFGkdoSIEg==
=tjpC
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-20 18:30 ` Matt Turner
2017-03-20 19:39 ` [Mesa-dev] " Emil Velikov
2017-03-21 5:10 ` Jonathan Gray
@ 2017-03-24 16:58 ` randyf
2 siblings, 0 replies; 94+ messages in thread
From: randyf @ 2017-03-24 16:58 UTC (permalink / raw)
To: Matt Turner
Cc: ML mesa-dev, Emil Velikov, Jason Ekstrand, ML dri-devel, Dylan Baker
On Mon, 20 Mar 2017, Matt Turner wrote:
>
>> - dropping the Autotools will lead to OpenBSD and NetBSD having to
>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>> boat.
>
> Solaris is a closed source operating system whose developers do not
> contribute to the project. We do not need to base our decisions on
> them.
>
For the parts that are relevant to this discussion, this isn't true.
Yes, the core OS is closed (Oracle Solaris, not the OpenSolaris
derivative), but the entire graphics stack, including kernel graphics
drivers are available on java.net and/or github.
That developers haven't been contributing is primarily due to a
significant amount of work required on a small set of developers in an
attempt to just catch up, but they are listening. What a migration to
new build system would mean is another item in the list requiring more
catch-up.
That said (and I hope I don't get into too hot water), I don't think it
would be an extremely difficult task for Solaris to migrate; just would
require resources.
Cheers!
---- Randy
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 13:42 ` Jose Fonseca
@ 2017-03-24 17:13 ` Dylan Baker
2017-03-24 17:51 ` Eric Anholt
2017-03-24 19:10 ` Kristian Høgsberg
1 sibling, 1 reply; 94+ messages in thread
From: Dylan Baker @ 2017-03-24 17:13 UTC (permalink / raw)
To: Jose Fonseca; +Cc: mesa-dev, Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 3459 bytes --]
Quoting Jose Fonseca (2017-03-24 06:42:18)
>
> I tend to disagree. While we can't avoid a transitory period, when we
> embark on another build system (Meson or something else) I think we
> should aim at 1) ensure such tool can indeed _completely_ replace at
> least _one_ existing build system, 2) and aim at migration quickly.
>
> Otherwise we'll just end up with yet another build system, yet another
> way builds can fail, with some developers stuck on old build systems
> because it works, or because the new build system quite doesn't work.
>
> And this is from (painful) experience.
I tend to agree. Meson is *nice* because it's faster than autotools, but it's
simplicity and the fact that it works for windows and *nix systems is one of the
best features. Having fewer build systems is better than more.
We had hoped that we could do one release with both autotools and meson, to give
some of the fast moving linux distributions (Arch, Fedora, etc) a chance to help
us iron out bugs, especially for pacakgers. I think it is important though to
make a commitment for exactly when we're going to either migrate completely to
meson, or abandon the attempt and revert it.
> So I think we should identify stake holders soon, collect requirements
> (OSes platforms, etc), make sure the prospective tool meets them, have
> all stakeholders collaborate on a prototype, them embark on mass migration.
>
> That is, if this fails, let it fail early. If it succeeds, may it
> succeed early. Anything but a slow death / zombie life.
I have a branch that builds intel's Vulkan driver, I'm actively working to get
intel's i965 dri driver and llvmpipe building and send that out as an RFC to
mesa-dev. That should give us enough of mesa to evaluate the build system I
hope (Since it touches all of the major mesa components [classic, gallium,
neither]).
If other people are interested in collaborating I'd be happy to push the branch
sooner so that others can look at it.
I also think it's worth talking to Eric (who said he's porting X to meson),
Daniel Stone (who has patches to port weston to meson), and Peter Hutterer (who
has patches to port libinput to meson). If they're serious about seeing those
land meson is even more appealing, since it would be a single build system that
all of the *nix graphics stack would be moving towards, and would mean that we
wouldn't have an "Autotools for xorg", "meson for weston and libinput", "cmake for
piglit", and "<other build system> for mesa".
> BTW, how about migrating mesademos to Meson? It currently has autotools
> and cmake. I was hoping that cmake would replace autotools, but I
> couldn't run fast enough, so I couldn't practice what preached above,
> hence cmake doing almost but not all what autotools does.
>
> And is not a crucial project for Linux distros -- few distros package it
> -- and even if they do, no other package would depend on it. And is one
> of those sort of projects that should be easy to port to any build too.
That's definitely doable, but most distros do package it, it's where glxgears,
and more importantly glxinfo live.
I'll have a look at it and see. At the very least we should be able to drop
cmake since I very much doubt anyone but you guys use it.
> Even if we ignore everything else, just replacing autotools + cmake with
> just one thing would be a net win.
>
>
> Jose
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljVU6UACgkQCJ4WlhQG
iO/UxwgAme1mn2lLw+afkUvemzd4/vrsmUVKj2B/bLxK+w3hoLAI2hCm+39yGLIr
FbDpxefM2uMhl5SYzHvIqMoJP/OxK6kZQb9LS0hGvkiBLw2oKAKFi61PTWH8ipVG
r0WUtT3wFTHoH0DLvdSHmSG43QKb25KSYpFimTG6ih1rZpCayweWOyPIMUoFBGUy
Fu+GU5142+/j3ht7242fjSai2fwhhyPHIAA+EBf8wMvqXicMjQNJJ/J3Gg8kQFa3
0euz2lxPhDFeFfOZxWdC+Jy+7doEIVfReChaCUo02exit2SmZqTJe+jpD6/h/09q
uwHQAheYR1565mA+gsUhyEGqdOWEug==
=f6Uu
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 17:13 ` Dylan Baker
@ 2017-03-24 17:51 ` Eric Anholt
2017-03-24 18:34 ` [Mesa-dev] " Daniel Stone
0 siblings, 1 reply; 94+ messages in thread
From: Eric Anholt @ 2017-03-24 17:51 UTC (permalink / raw)
To: Dylan Baker, Jose Fonseca; +Cc: mesa-dev, Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 2899 bytes --]
Dylan Baker <dylan@pnwbakers.com> writes:
> [ Unknown signature status ]
> Quoting Jose Fonseca (2017-03-24 06:42:18)
>>
>> I tend to disagree. While we can't avoid a transitory period, when we
>> embark on another build system (Meson or something else) I think we
>> should aim at 1) ensure such tool can indeed _completely_ replace at
>> least _one_ existing build system, 2) and aim at migration quickly.
>>
>> Otherwise we'll just end up with yet another build system, yet another
>> way builds can fail, with some developers stuck on old build systems
>> because it works, or because the new build system quite doesn't work.
>>
>> And this is from (painful) experience.
>
> I tend to agree. Meson is *nice* because it's faster than autotools, but it's
> simplicity and the fact that it works for windows and *nix systems is one of the
> best features. Having fewer build systems is better than more.
>
> We had hoped that we could do one release with both autotools and meson, to give
> some of the fast moving linux distributions (Arch, Fedora, etc) a chance to help
> us iron out bugs, especially for pacakgers. I think it is important though to
> make a commitment for exactly when we're going to either migrate completely to
> meson, or abandon the attempt and revert it.
>
>> So I think we should identify stake holders soon, collect requirements
>> (OSes platforms, etc), make sure the prospective tool meets them, have
>> all stakeholders collaborate on a prototype, them embark on mass migration.
>>
>> That is, if this fails, let it fail early. If it succeeds, may it
>> succeed early. Anything but a slow death / zombie life.
>
> I have a branch that builds intel's Vulkan driver, I'm actively working to get
> intel's i965 dri driver and llvmpipe building and send that out as an RFC to
> mesa-dev. That should give us enough of mesa to evaluate the build system I
> hope (Since it touches all of the major mesa components [classic, gallium,
> neither]).
>
> If other people are interested in collaborating I'd be happy to push the branch
> sooner so that others can look at it.
>
> I also think it's worth talking to Eric (who said he's porting X to meson),
> Daniel Stone (who has patches to port weston to meson), and Peter Hutterer (who
> has patches to port libinput to meson). If they're serious about seeing those
> land meson is even more appealing, since it would be a single build system that
> all of the *nix graphics stack would be moving towards, and would mean that we
> wouldn't have an "Autotools for xorg", "meson for weston and libinput", "cmake for
> piglit", and "<other build system> for mesa".
My desire is to push enough of X.org to Meson that I can actually do CI
of the X Server. Right now CI is not really tractable on Travis because
autogen.sh of all the dependencies takes too long.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 17:51 ` Eric Anholt
@ 2017-03-24 18:34 ` Daniel Stone
0 siblings, 0 replies; 94+ messages in thread
From: Daniel Stone @ 2017-03-24 18:34 UTC (permalink / raw)
To: Eric Anholt
Cc: mesa-dev, Jose Fonseca, Maling list - DRI developers, Dylan Baker
Hi,
On 24 March 2017 at 17:51, Eric Anholt <eric@anholt.net> wrote:
> Dylan Baker <dylan@pnwbakers.com> writes:
>> I also think it's worth talking to Eric (who said he's porting X to meson),
>> Daniel Stone (who has patches to port weston to meson), and Peter Hutterer (who
>> has patches to port libinput to meson). If they're serious about seeing those
>> land meson is even more appealing, since it would be a single build system that
>> all of the *nix graphics stack would be moving towards, and would mean that we
>> wouldn't have an "Autotools for xorg", "meson for weston and libinput", "cmake for
>> piglit", and "<other build system> for mesa".
>
> My desire is to push enough of X.org to Meson that I can actually do CI
> of the X Server. Right now CI is not really tractable on Travis because
> autogen.sh of all the dependencies takes too long.
... and I'm equally serious about Wayland/Weston. I find how slow it
is infuriating for personal development, but for CI, it means that
there's no point trying to test different build options, since the
overhead is so high. Meson would let us actually do that.
I understand there's a huge amount of acquired folk knowledge we're
throwing away with autotools, and in the ~13 years since I started
working on moving X.Org to autotools, I've evaluated and discarded
most of the others because I didn't think they were sufficiently
compelling to do so. In terms of its featureset,
accessibility/tractability to mere mortals, etc, Meson is the only one
I've found where the advantages of moving outweighed the
disadvantages.
I've been pretty buried in atomic work lately, but am going to send
out a revised patchset for Wayland & Weston after I've got the next
iteration out. Similarly I'd expect to see one or two releases
shipping with both build systems, whilst we work with downstreams to
beat any bugs out of the new system before cutting over.
Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 13:42 ` Jose Fonseca
2017-03-24 17:13 ` Dylan Baker
@ 2017-03-24 19:10 ` Kristian Høgsberg
2017-03-24 19:44 ` Jose Fonseca
2017-03-24 21:09 ` [Mesa-dev] " Rob Clark
1 sibling, 2 replies; 94+ messages in thread
From: Kristian Høgsberg @ 2017-03-24 19:10 UTC (permalink / raw)
To: Jose Fonseca; +Cc: mesa-dev, Maling list - DRI developers
On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca <jfonseca@vmware.com> wrote:
> On 23/03/17 01:38, Rob Clark wrote:
>>
>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
>>>
>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>>>
>>>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher@gmail.com>
>>>> wrote:
>>>>>
>>>>> I guess I'm a little late to the party here, but I haven't had time to
>>>>> really let all of this sink in and actually look at meson. It doesn't
>>>>> seem so bad with a quick look and I think I could probably sort it out
>>>>> when the time came, but there would still be a bit of a learning
>>>>> curve. While that may not be a big deal at the micro level, I have
>>>>> concerns at the macro level.
>>>>>
>>>>> First, I'm concerned it may discourage casual developers and
>>>>> packagers. autotools isn't great, but most people are familiar enough
>>>>> with it that they can get by. Most people have enough knowledge of
>>>>> autotools that they can pretty easily diagnose a configuration based
>>>>> failure. There are a lot of resources for autotools. I'm not sure
>>>>> that would be the case for meson. Do we as a community feel we have
>>>>> enough meson experience to get people over the hump? Anything that
>>>>> makes it harder for someone to try a new build or do a bisect is a big
>>>>> problem in my opinion.
>>>>
>>>>
>>>> One of the things that's prompted this on our side (I've talked this
>>>> over with
>>>> other people at Intel before starting), was that clearly we *don't* know
>>>> autotools well enough to get it right. Emil almost always finds cases
>>>> were we've
>>>> done things *almost*, but not quite right.
>>>>
>>>> For my part, it took me about 3 or 4 days of reading through the docs
>>>> and
>>>> writing the libdrm port to get it right, and a lot of that is just the
>>>> boilerplate of having ~8 drivers that all need basically the same logic.
>>>>
>>>>> Next, my bigger concern is for distro and casual packagers and people
>>>>> that maintain large build systems with lots of existing custom
>>>>> configurations. Changing from autotools would basically require many
>>>>> of these existing tools and systems to be rewritten and then deal with
>>>>> the debugging and fall out from that. The potential decreased build
>>>>> time is a nice bonus, but frankly a lot of people/companies have years
>>>>> of investment in existing tools.
>>>>
>>>>
>>>> Sure, but we're also not the only ones investigating meson. Gnome is
>>>> using it
>>>> already, libepoxy is using it, gstreamer is using it. There are patches
>>>> for
>>>> weston (written by Daniel Stone) and libinput (written by Peter
>>>> Hutterer), there
>>>> are some other projects in the graphics sphere that people are working
>>>> on. So
>>>> even if we as a community decide that meson isn't for us, it's not going
>>>> away.
>>>
>>>
>>> It is worth pointing out that it is currently required by no component
>>> of an x.org stack. In the case of libepoxy it was added by a new
>>> maintainer
>>> on a new release and even then autoconf remains.
>>>
>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>> currently requires meson to build including gnome and gstreamer.
>>>
>>
>> but I guess that is conflating two completely different topics..
>> addition of meson and removal of autotools. It is probably better
>> that we treat the topics separately. I don't see any way that the two
>> can happen at the same time.
>>
>> The autotools build probably needs to remain for at least a couple
>> releases, and I certainly wouldn't mind if some of the other desktop
>> projects took the leap of dropping autotools first (at least then
>> various different "distro" consumers will have already dealt with how
>> to build meson packages)
>>
>> None of that blocks addition of a meson build system (or what various
>> developers use day to day)
>>
>> BR,
>> -R
>
>
> I tend to disagree. While we can't avoid a transitory period, when we
> embark on another build system (Meson or something else) I think we should
> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
> existing build system, 2) and aim at migration quickly.
>
> Otherwise we'll just end up with yet another build system, yet another way
> builds can fail, with some developers stuck on old build systems because it
> works, or because the new build system quite doesn't work.
>
> And this is from (painful) experience.
I agree, adding a meson build system should aim to phase out one of
the other build systems within one or two release cycles. But (and
maybe that was Robs point) that doesn't have be autotools. What if we
phase out scons? It doesn't seem like anybody is really attached to it
and if meson is as good as scons on windows, then if nothing else
happens we end up with the same number of build systems. What's more
likely to happen is that a lot of Linux developers (and CI systems)
will also start using meson, which means that life gets easier for
vmware wrt maintaining the build system, and easier for all developers
who have spent to much of their life waiting for autogen.sh. Then
decommissioning autotools can be a separate topic as Rob suggests,
something we'll do when the world is ready.
Kristian
>
>
> So I think we should identify stake holders soon, collect requirements (OSes
> platforms, etc), make sure the prospective tool meets them, have all
> stakeholders collaborate on a prototype, them embark on mass migration.
>
> That is, if this fails, let it fail early. If it succeeds, may it succeed
> early. Anything but a slow death / zombie life.
>
>
>
> BTW, how about migrating mesademos to Meson? It currently has autotools and
> cmake. I was hoping that cmake would replace autotools, but I couldn't run
> fast enough, so I couldn't practice what preached above, hence cmake doing
> almost but not all what autotools does.
>
> And is not a crucial project for Linux distros -- few distros package it --
> and even if they do, no other package would depend on it. And is one of
> those sort of projects that should be easy to port to any build too.
>
> Even if we ignore everything else, just replacing autotools + cmake with
> just one thing would be a net win.
>
>
> Jose
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 19:10 ` Kristian Høgsberg
@ 2017-03-24 19:44 ` Jose Fonseca
2017-03-24 20:08 ` Kristian Høgsberg
2017-03-24 21:09 ` [Mesa-dev] " Rob Clark
1 sibling, 1 reply; 94+ messages in thread
From: Jose Fonseca @ 2017-03-24 19:44 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: mesa-dev, Maling list - DRI developers
On 24/03/17 19:10, Kristian Høgsberg wrote:
> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca <jfonseca@vmware.com> wrote:
>> On 23/03/17 01:38, Rob Clark wrote:
>>>
>>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
>>>>
>>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>>>>
>>>>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> I guess I'm a little late to the party here, but I haven't had time to
>>>>>> really let all of this sink in and actually look at meson. It doesn't
>>>>>> seem so bad with a quick look and I think I could probably sort it out
>>>>>> when the time came, but there would still be a bit of a learning
>>>>>> curve. While that may not be a big deal at the micro level, I have
>>>>>> concerns at the macro level.
>>>>>>
>>>>>> First, I'm concerned it may discourage casual developers and
>>>>>> packagers. autotools isn't great, but most people are familiar enough
>>>>>> with it that they can get by. Most people have enough knowledge of
>>>>>> autotools that they can pretty easily diagnose a configuration based
>>>>>> failure. There are a lot of resources for autotools. I'm not sure
>>>>>> that would be the case for meson. Do we as a community feel we have
>>>>>> enough meson experience to get people over the hump? Anything that
>>>>>> makes it harder for someone to try a new build or do a bisect is a big
>>>>>> problem in my opinion.
>>>>>
>>>>>
>>>>> One of the things that's prompted this on our side (I've talked this
>>>>> over with
>>>>> other people at Intel before starting), was that clearly we *don't* know
>>>>> autotools well enough to get it right. Emil almost always finds cases
>>>>> were we've
>>>>> done things *almost*, but not quite right.
>>>>>
>>>>> For my part, it took me about 3 or 4 days of reading through the docs
>>>>> and
>>>>> writing the libdrm port to get it right, and a lot of that is just the
>>>>> boilerplate of having ~8 drivers that all need basically the same logic.
>>>>>
>>>>>> Next, my bigger concern is for distro and casual packagers and people
>>>>>> that maintain large build systems with lots of existing custom
>>>>>> configurations. Changing from autotools would basically require many
>>>>>> of these existing tools and systems to be rewritten and then deal with
>>>>>> the debugging and fall out from that. The potential decreased build
>>>>>> time is a nice bonus, but frankly a lot of people/companies have years
>>>>>> of investment in existing tools.
>>>>>
>>>>>
>>>>> Sure, but we're also not the only ones investigating meson. Gnome is
>>>>> using it
>>>>> already, libepoxy is using it, gstreamer is using it. There are patches
>>>>> for
>>>>> weston (written by Daniel Stone) and libinput (written by Peter
>>>>> Hutterer), there
>>>>> are some other projects in the graphics sphere that people are working
>>>>> on. So
>>>>> even if we as a community decide that meson isn't for us, it's not going
>>>>> away.
>>>>
>>>>
>>>> It is worth pointing out that it is currently required by no component
>>>> of an x.org stack. In the case of libepoxy it was added by a new
>>>> maintainer
>>>> on a new release and even then autoconf remains.
>>>>
>>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>>> currently requires meson to build including gnome and gstreamer.
>>>>
>>>
>>> but I guess that is conflating two completely different topics..
>>> addition of meson and removal of autotools. It is probably better
>>> that we treat the topics separately. I don't see any way that the two
>>> can happen at the same time.
>>>
>>> The autotools build probably needs to remain for at least a couple
>>> releases, and I certainly wouldn't mind if some of the other desktop
>>> projects took the leap of dropping autotools first (at least then
>>> various different "distro" consumers will have already dealt with how
>>> to build meson packages)
>>>
>>> None of that blocks addition of a meson build system (or what various
>>> developers use day to day)
>>>
>>> BR,
>>> -R
>>
>>
>> I tend to disagree. While we can't avoid a transitory period, when we
>> embark on another build system (Meson or something else) I think we should
>> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
>> existing build system, 2) and aim at migration quickly.
>>
>> Otherwise we'll just end up with yet another build system, yet another way
>> builds can fail, with some developers stuck on old build systems because it
>> works, or because the new build system quite doesn't work.
>>
>> And this is from (painful) experience.
>
> I agree, adding a meson build system should aim to phase out one of
> the other build systems within one or two release cycles. But (and
> maybe that was Robs point) that doesn't have be autotools. What if we
> phase out scons? It doesn't seem like anybody is really attached to it
> and if meson is as good as scons on windows, then if nothing else
> happens we end up with the same number of build systems. What's more
> likely to happen is that a lot of Linux developers (and CI systems)
> will also start using meson, which means that life gets easier for
> vmware wrt maintaining the build system, and easier for all developers
> who have spent to much of their life waiting for autogen.sh. Then
> decommissioning autotools can be a separate topic as Rob suggests,
> something we'll do when the world is ready.
There's zero overlap between SCons build users and Meson experience, so
I don't see how that would work. Who would lead the charge?
Hence my suggestion of mesademos as guinea pig. If someone gets
mesademos building with Meson for Linux then the exercise of getting it
to build for Windows w/ MSVC/MinGW would allows us to get acquainted
with the tool. And unifying mesademos build is a worthy goal on its own
right -- it wouldn't be throwaway work.
I wouldn't mind another "tools" project like Piglit. But the issue with
all these projects is that they are way more complex and fast moving
targets. mesademos is pretty slow moving -- there are often many months
between commits.
Just my 2c.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 19:44 ` Jose Fonseca
@ 2017-03-24 20:08 ` Kristian Høgsberg
2017-03-24 21:16 ` Jose Fonseca
0 siblings, 1 reply; 94+ messages in thread
From: Kristian Høgsberg @ 2017-03-24 20:08 UTC (permalink / raw)
To: Jose Fonseca; +Cc: mesa-dev, Maling list - DRI developers
On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca <jfonseca@vmware.com> wrote:
> On 24/03/17 19:10, Kristian Høgsberg wrote:
>>
>> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca <jfonseca@vmware.com> wrote:
>>>
>>> On 23/03/17 01:38, Rob Clark wrote:
>>>>
>>>>
>>>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
>>>>>
>>>>>
>>>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> I guess I'm a little late to the party here, but I haven't had time
>>>>>>> to
>>>>>>> really let all of this sink in and actually look at meson. It
>>>>>>> doesn't
>>>>>>> seem so bad with a quick look and I think I could probably sort it
>>>>>>> out
>>>>>>> when the time came, but there would still be a bit of a learning
>>>>>>> curve. While that may not be a big deal at the micro level, I have
>>>>>>> concerns at the macro level.
>>>>>>>
>>>>>>> First, I'm concerned it may discourage casual developers and
>>>>>>> packagers. autotools isn't great, but most people are familiar
>>>>>>> enough
>>>>>>> with it that they can get by. Most people have enough knowledge of
>>>>>>> autotools that they can pretty easily diagnose a configuration based
>>>>>>> failure. There are a lot of resources for autotools. I'm not sure
>>>>>>> that would be the case for meson. Do we as a community feel we have
>>>>>>> enough meson experience to get people over the hump? Anything that
>>>>>>> makes it harder for someone to try a new build or do a bisect is a
>>>>>>> big
>>>>>>> problem in my opinion.
>>>>>>
>>>>>>
>>>>>>
>>>>>> One of the things that's prompted this on our side (I've talked this
>>>>>> over with
>>>>>> other people at Intel before starting), was that clearly we *don't*
>>>>>> know
>>>>>> autotools well enough to get it right. Emil almost always finds cases
>>>>>> were we've
>>>>>> done things *almost*, but not quite right.
>>>>>>
>>>>>> For my part, it took me about 3 or 4 days of reading through the docs
>>>>>> and
>>>>>> writing the libdrm port to get it right, and a lot of that is just the
>>>>>> boilerplate of having ~8 drivers that all need basically the same
>>>>>> logic.
>>>>>>
>>>>>>> Next, my bigger concern is for distro and casual packagers and people
>>>>>>> that maintain large build systems with lots of existing custom
>>>>>>> configurations. Changing from autotools would basically require many
>>>>>>> of these existing tools and systems to be rewritten and then deal
>>>>>>> with
>>>>>>> the debugging and fall out from that. The potential decreased build
>>>>>>> time is a nice bonus, but frankly a lot of people/companies have
>>>>>>> years
>>>>>>> of investment in existing tools.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sure, but we're also not the only ones investigating meson. Gnome is
>>>>>> using it
>>>>>> already, libepoxy is using it, gstreamer is using it. There are
>>>>>> patches
>>>>>> for
>>>>>> weston (written by Daniel Stone) and libinput (written by Peter
>>>>>> Hutterer), there
>>>>>> are some other projects in the graphics sphere that people are working
>>>>>> on. So
>>>>>> even if we as a community decide that meson isn't for us, it's not
>>>>>> going
>>>>>> away.
>>>>>
>>>>>
>>>>>
>>>>> It is worth pointing out that it is currently required by no component
>>>>> of an x.org stack. In the case of libepoxy it was added by a new
>>>>> maintainer
>>>>> on a new release and even then autoconf remains.
>>>>>
>>>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>>>> currently requires meson to build including gnome and gstreamer.
>>>>>
>>>>
>>>> but I guess that is conflating two completely different topics..
>>>> addition of meson and removal of autotools. It is probably better
>>>> that we treat the topics separately. I don't see any way that the two
>>>> can happen at the same time.
>>>>
>>>> The autotools build probably needs to remain for at least a couple
>>>> releases, and I certainly wouldn't mind if some of the other desktop
>>>> projects took the leap of dropping autotools first (at least then
>>>> various different "distro" consumers will have already dealt with how
>>>> to build meson packages)
>>>>
>>>> None of that blocks addition of a meson build system (or what various
>>>> developers use day to day)
>>>>
>>>> BR,
>>>> -R
>>>
>>>
>>>
>>> I tend to disagree. While we can't avoid a transitory period, when we
>>> embark on another build system (Meson or something else) I think we
>>> should
>>> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
>>> existing build system, 2) and aim at migration quickly.
>>>
>>> Otherwise we'll just end up with yet another build system, yet another
>>> way
>>> builds can fail, with some developers stuck on old build systems because
>>> it
>>> works, or because the new build system quite doesn't work.
>>>
>>> And this is from (painful) experience.
>>
>>
>> I agree, adding a meson build system should aim to phase out one of
>> the other build systems within one or two release cycles. But (and
>> maybe that was Robs point) that doesn't have be autotools. What if we
>> phase out scons? It doesn't seem like anybody is really attached to it
>> and if meson is as good as scons on windows, then if nothing else
>> happens we end up with the same number of build systems. What's more
>> likely to happen is that a lot of Linux developers (and CI systems)
>> will also start using meson, which means that life gets easier for
>> vmware wrt maintaining the build system, and easier for all developers
>> who have spent to much of their life waiting for autogen.sh. Then
>> decommissioning autotools can be a separate topic as Rob suggests,
>> something we'll do when the world is ready.
>
>
> There's zero overlap between SCons build users and Meson experience, so I
> don't see how that would work. Who would lead the charge?
It sounds like Dylan and the Intel team are interested in doing the
meson work. If that's the case, then perhaps you (or other SCons
users) would be willing to evaluate the result and see if it meets
your requirements for a SCons replacement?
Kristian
> Hence my suggestion of mesademos as guinea pig. If someone gets mesademos
> building with Meson for Linux then the exercise of getting it to build for
> Windows w/ MSVC/MinGW would allows us to get acquainted with the tool. And
> unifying mesademos build is a worthy goal on its own right -- it wouldn't be
> throwaway work.
>
> I wouldn't mind another "tools" project like Piglit. But the issue with all
> these projects is that they are way more complex and fast moving targets.
> mesademos is pretty slow moving -- there are often many months between
> commits.
>
> Just my 2c.
>
> Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 15:57 ` [Mesa-dev] " Matt Turner
2017-03-21 17:16 ` Emil Velikov
@ 2017-03-24 20:44 ` Chad Versace
2017-03-28 16:59 ` Emil Velikov
1 sibling, 1 reply; 94+ messages in thread
From: Chad Versace @ 2017-03-24 20:44 UTC (permalink / raw)
To: Matt Turner; +Cc: ML mesa-dev, Emil Velikov, ML dri-devel
On Tue 21 Mar 2017, Matt Turner wrote:
> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
> >> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> >>> These projects have been getting closer to upstream and "forcing" the
> >>> extra obstacle is effectively giving them the middle finger.
> >>
> >> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
> >>
> > Can we stop with the GCC thing ? Can we point to a place where we want
> > to use feature A introduced with GCC B and we don't ?
>
> Are you freaking serious?!
>
> This happens *all* the time. It happened like two days ago with commit
> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
> happened at least once in the previous month, and every month before
> that.
More examples:
- Jason and I wanted to use C11 generic expressions (that's what the
C11 spec calls them) in anvil, but old GCC => !C11.
- I *still* want to use _Generic.
- If we could use C11, then we could stop using the
include/c11/thread.h wrapper for the C11 thread features. We could use,
you know, *real* C11 threads instead of faking it.
- I want to do this:
#define let __auto_type
But __auto_type requires GCC 4.9
<https://gcc.gnu.org/gcc-4.9/changes.html> or a comparably dated clang.
- I want to use GCC's builtin overflow arithmetic functions
<https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html> (such as
__builtin_mul_overflow(), __builtin_add_overflow) where we currently do overflow checking by hand.
The builtin functions are more secure (no chance of stupid mistakes) and
faster (they simply do the arithmetic op then test the overflow flag in the
CPU's status register).
- I tend to be guilty occasionally breaking the build in
anvil code, due to old GCC. I think it happened again again this week:
freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | vulkan/anv_device.c:697:4: error: initializer element is not constant
freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
freenode.#dri-devel.log-2017-03-16 11:07:23 | imirkin_ | anyone seen this? i'm on HEAD
freenode.#dri-devel.log-2017-03-16 11:13:50 | vsyrjala | yep. gcc-4.9 strikes again?
freenode.#dri-devel.log-2017-03-16 11:14:54 | imirkin_ | i'm definitely using gcc-4.9
freenode.#dri-devel.log-2017-03-16 11:15:16 | vsyrjala | that '(VkExtent3D)' looks very much pointless there
freenode.#dri-devel.log-2017-03-16 11:15:56 | imirkin_ | 4.9.4 as it happens, which is the "stable" gcc on gentoo
freenode.#dri-devel.log:2017-03-16 11:18:04 | vsyrjala | looks like chadv broke it
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-21 18:06 ` Matt Turner
2017-03-21 18:56 ` [Mesa-dev] " Emil Velikov
@ 2017-03-24 20:59 ` Chad Versace
1 sibling, 0 replies; 94+ messages in thread
From: Chad Versace @ 2017-03-24 20:59 UTC (permalink / raw)
To: Matt Turner; +Cc: ML mesa-dev, Emil Velikov, ML dri-devel
On Tue 21 Mar 2017, Matt Turner wrote:
> On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > On 21 March 2017 at 15:57, Matt Turner <mattst88@gmail.com> wrote:
> >> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> >>> On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
> >>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
> Let me try one last time:
>
> (1) Non-recursive automake is necessary for parallel build performance
> (2) Non-recursive automake is intractably unmaintainable for
> sufficiently large projects
> (3) Mesa is a sufficiently large project
>
> Therefore using automake will be either bad for parallel build
> performance, unmaintainable, or both.
>
> Meson aims to be a build system actually capable of replacing
> autotools (IMO unlike cmake, scons, waf, et al.). It offers a much
> cleaner domain specific language for writing the build rules, while
> generating non-recursive ninja build files. It does not use libtool.
> It supports Windows. It supports cross compilation.
>
> And it has momentum: libepoxy already has a Meson build system. Others
> in the X.Org community are experimenting with it for libinput, Wayland
> and Weston, and the xserver.
>
> All of that makes Meson very compelling.
Matt, I just wanted to say thanks for capturing in a nutshell the
argument for a Meson trial.
I want Meson because my builds are too slow. I regularly build an entire
fucking operating system from scratch (Chrome OS), and I cry when top
shows only 1 core at 100% and the other 47 cores sitting idle.
Autotools and libtool are often the culprit. The libtool penalty is paid
on every build, not just at configure time.
The only way to get all 48 cores closer to 100% is to (1) use
a non-recursive build system that (2) doesnt' use shell nor (3) libtool.
I don't care about new shiny. I'm often wary of new shiny things that
receive too much excitement. Meson is a such a new shiny. But I'm
willing to overlook my aversion to new shiny Meson's immaturity if
it makes Chrome OS build faster... at least for Mesa.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 19:10 ` Kristian Høgsberg
2017-03-24 19:44 ` Jose Fonseca
@ 2017-03-24 21:09 ` Rob Clark
1 sibling, 0 replies; 94+ messages in thread
From: Rob Clark @ 2017-03-24 21:09 UTC (permalink / raw)
To: Kristian Høgsberg
Cc: mesa-dev, Jose Fonseca, Maling list - DRI developers
On Fri, Mar 24, 2017 at 3:10 PM, Kristian Høgsberg <hoegsberg@gmail.com> wrote:
> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca <jfonseca@vmware.com> wrote:
>> On 23/03/17 01:38, Rob Clark wrote:
>>>
>>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
>>>>
>>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>>>>
>>>>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> I guess I'm a little late to the party here, but I haven't had time to
>>>>>> really let all of this sink in and actually look at meson. It doesn't
>>>>>> seem so bad with a quick look and I think I could probably sort it out
>>>>>> when the time came, but there would still be a bit of a learning
>>>>>> curve. While that may not be a big deal at the micro level, I have
>>>>>> concerns at the macro level.
>>>>>>
>>>>>> First, I'm concerned it may discourage casual developers and
>>>>>> packagers. autotools isn't great, but most people are familiar enough
>>>>>> with it that they can get by. Most people have enough knowledge of
>>>>>> autotools that they can pretty easily diagnose a configuration based
>>>>>> failure. There are a lot of resources for autotools. I'm not sure
>>>>>> that would be the case for meson. Do we as a community feel we have
>>>>>> enough meson experience to get people over the hump? Anything that
>>>>>> makes it harder for someone to try a new build or do a bisect is a big
>>>>>> problem in my opinion.
>>>>>
>>>>>
>>>>> One of the things that's prompted this on our side (I've talked this
>>>>> over with
>>>>> other people at Intel before starting), was that clearly we *don't* know
>>>>> autotools well enough to get it right. Emil almost always finds cases
>>>>> were we've
>>>>> done things *almost*, but not quite right.
>>>>>
>>>>> For my part, it took me about 3 or 4 days of reading through the docs
>>>>> and
>>>>> writing the libdrm port to get it right, and a lot of that is just the
>>>>> boilerplate of having ~8 drivers that all need basically the same logic.
>>>>>
>>>>>> Next, my bigger concern is for distro and casual packagers and people
>>>>>> that maintain large build systems with lots of existing custom
>>>>>> configurations. Changing from autotools would basically require many
>>>>>> of these existing tools and systems to be rewritten and then deal with
>>>>>> the debugging and fall out from that. The potential decreased build
>>>>>> time is a nice bonus, but frankly a lot of people/companies have years
>>>>>> of investment in existing tools.
>>>>>
>>>>>
>>>>> Sure, but we're also not the only ones investigating meson. Gnome is
>>>>> using it
>>>>> already, libepoxy is using it, gstreamer is using it. There are patches
>>>>> for
>>>>> weston (written by Daniel Stone) and libinput (written by Peter
>>>>> Hutterer), there
>>>>> are some other projects in the graphics sphere that people are working
>>>>> on. So
>>>>> even if we as a community decide that meson isn't for us, it's not going
>>>>> away.
>>>>
>>>>
>>>> It is worth pointing out that it is currently required by no component
>>>> of an x.org stack. In the case of libepoxy it was added by a new
>>>> maintainer
>>>> on a new release and even then autoconf remains.
>>>>
>>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>>> currently requires meson to build including gnome and gstreamer.
>>>>
>>>
>>> but I guess that is conflating two completely different topics..
>>> addition of meson and removal of autotools. It is probably better
>>> that we treat the topics separately. I don't see any way that the two
>>> can happen at the same time.
>>>
>>> The autotools build probably needs to remain for at least a couple
>>> releases, and I certainly wouldn't mind if some of the other desktop
>>> projects took the leap of dropping autotools first (at least then
>>> various different "distro" consumers will have already dealt with how
>>> to build meson packages)
>>>
>>> None of that blocks addition of a meson build system (or what various
>>> developers use day to day)
>>>
>>> BR,
>>> -R
>>
>>
>> I tend to disagree. While we can't avoid a transitory period, when we
>> embark on another build system (Meson or something else) I think we should
>> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
>> existing build system, 2) and aim at migration quickly.
>>
>> Otherwise we'll just end up with yet another build system, yet another way
>> builds can fail, with some developers stuck on old build systems because it
>> works, or because the new build system quite doesn't work.
>>
>> And this is from (painful) experience.
>
> I agree, adding a meson build system should aim to phase out one of
> the other build systems within one or two release cycles. But (and
> maybe that was Robs point) that doesn't have be autotools. What if we
> phase out scons? It doesn't seem like anybody is really attached to it
> and if meson is as good as scons on windows, then if nothing else
> happens we end up with the same number of build systems. What's more
> likely to happen is that a lot of Linux developers (and CI systems)
> will also start using meson, which means that life gets easier for
> vmware wrt maintaining the build system, and easier for all developers
> who have spent to much of their life waiting for autogen.sh. Then
> decommissioning autotools can be a separate topic as Rob suggests,
> something we'll do when the world is ready.
yup, that was basically my point.. scons seemed like an easier first target
BR,
-R
> Kristian
>
>>
>>
>> So I think we should identify stake holders soon, collect requirements (OSes
>> platforms, etc), make sure the prospective tool meets them, have all
>> stakeholders collaborate on a prototype, them embark on mass migration.
>>
>> That is, if this fails, let it fail early. If it succeeds, may it succeed
>> early. Anything but a slow death / zombie life.
>>
>>
>>
>> BTW, how about migrating mesademos to Meson? It currently has autotools and
>> cmake. I was hoping that cmake would replace autotools, but I couldn't run
>> fast enough, so I couldn't practice what preached above, hence cmake doing
>> almost but not all what autotools does.
>>
>> And is not a crucial project for Linux distros -- few distros package it --
>> and even if they do, no other package would depend on it. And is one of
>> those sort of projects that should be easy to port to any build too.
>>
>> Even if we ignore everything else, just replacing autotools + cmake with
>> just one thing would be a net win.
>>
>>
>> Jose
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 20:08 ` Kristian Høgsberg
@ 2017-03-24 21:16 ` Jose Fonseca
2017-03-24 21:20 ` Jason Ekstrand
` (2 more replies)
0 siblings, 3 replies; 94+ messages in thread
From: Jose Fonseca @ 2017-03-24 21:16 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: mesa-dev, Maling list - DRI developers
On 24/03/17 20:08, Kristian Høgsberg wrote:
> On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca <jfonseca@vmware.com> wrote:
>> On 24/03/17 19:10, Kristian Høgsberg wrote:
>>>
>>> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca <jfonseca@vmware.com> wrote:
>>>>
>>>> On 23/03/17 01:38, Rob Clark wrote:
>>>>>
>>>>>
>>>>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <alexdeucher@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> I guess I'm a little late to the party here, but I haven't had time
>>>>>>>> to
>>>>>>>> really let all of this sink in and actually look at meson. It
>>>>>>>> doesn't
>>>>>>>> seem so bad with a quick look and I think I could probably sort it
>>>>>>>> out
>>>>>>>> when the time came, but there would still be a bit of a learning
>>>>>>>> curve. While that may not be a big deal at the micro level, I have
>>>>>>>> concerns at the macro level.
>>>>>>>>
>>>>>>>> First, I'm concerned it may discourage casual developers and
>>>>>>>> packagers. autotools isn't great, but most people are familiar
>>>>>>>> enough
>>>>>>>> with it that they can get by. Most people have enough knowledge of
>>>>>>>> autotools that they can pretty easily diagnose a configuration based
>>>>>>>> failure. There are a lot of resources for autotools. I'm not sure
>>>>>>>> that would be the case for meson. Do we as a community feel we have
>>>>>>>> enough meson experience to get people over the hump? Anything that
>>>>>>>> makes it harder for someone to try a new build or do a bisect is a
>>>>>>>> big
>>>>>>>> problem in my opinion.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> One of the things that's prompted this on our side (I've talked this
>>>>>>> over with
>>>>>>> other people at Intel before starting), was that clearly we *don't*
>>>>>>> know
>>>>>>> autotools well enough to get it right. Emil almost always finds cases
>>>>>>> were we've
>>>>>>> done things *almost*, but not quite right.
>>>>>>>
>>>>>>> For my part, it took me about 3 or 4 days of reading through the docs
>>>>>>> and
>>>>>>> writing the libdrm port to get it right, and a lot of that is just the
>>>>>>> boilerplate of having ~8 drivers that all need basically the same
>>>>>>> logic.
>>>>>>>
>>>>>>>> Next, my bigger concern is for distro and casual packagers and people
>>>>>>>> that maintain large build systems with lots of existing custom
>>>>>>>> configurations. Changing from autotools would basically require many
>>>>>>>> of these existing tools and systems to be rewritten and then deal
>>>>>>>> with
>>>>>>>> the debugging and fall out from that. The potential decreased build
>>>>>>>> time is a nice bonus, but frankly a lot of people/companies have
>>>>>>>> years
>>>>>>>> of investment in existing tools.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sure, but we're also not the only ones investigating meson. Gnome is
>>>>>>> using it
>>>>>>> already, libepoxy is using it, gstreamer is using it. There are
>>>>>>> patches
>>>>>>> for
>>>>>>> weston (written by Daniel Stone) and libinput (written by Peter
>>>>>>> Hutterer), there
>>>>>>> are some other projects in the graphics sphere that people are working
>>>>>>> on. So
>>>>>>> even if we as a community decide that meson isn't for us, it's not
>>>>>>> going
>>>>>>> away.
>>>>>>
>>>>>>
>>>>>>
>>>>>> It is worth pointing out that it is currently required by no component
>>>>>> of an x.org stack. In the case of libepoxy it was added by a new
>>>>>> maintainer
>>>>>> on a new release and even then autoconf remains.
>>>>>>
>>>>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>>>>> currently requires meson to build including gnome and gstreamer.
>>>>>>
>>>>>
>>>>> but I guess that is conflating two completely different topics..
>>>>> addition of meson and removal of autotools. It is probably better
>>>>> that we treat the topics separately. I don't see any way that the two
>>>>> can happen at the same time.
>>>>>
>>>>> The autotools build probably needs to remain for at least a couple
>>>>> releases, and I certainly wouldn't mind if some of the other desktop
>>>>> projects took the leap of dropping autotools first (at least then
>>>>> various different "distro" consumers will have already dealt with how
>>>>> to build meson packages)
>>>>>
>>>>> None of that blocks addition of a meson build system (or what various
>>>>> developers use day to day)
>>>>>
>>>>> BR,
>>>>> -R
>>>>
>>>>
>>>>
>>>> I tend to disagree. While we can't avoid a transitory period, when we
>>>> embark on another build system (Meson or something else) I think we
>>>> should
>>>> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
>>>> existing build system, 2) and aim at migration quickly.
>>>>
>>>> Otherwise we'll just end up with yet another build system, yet another
>>>> way
>>>> builds can fail, with some developers stuck on old build systems because
>>>> it
>>>> works, or because the new build system quite doesn't work.
>>>>
>>>> And this is from (painful) experience.
>>>
>>>
>>> I agree, adding a meson build system should aim to phase out one of
>>> the other build systems within one or two release cycles. But (and
>>> maybe that was Robs point) that doesn't have be autotools. What if we
>>> phase out scons? It doesn't seem like anybody is really attached to it
>>> and if meson is as good as scons on windows, then if nothing else
>>> happens we end up with the same number of build systems. What's more
>>> likely to happen is that a lot of Linux developers (and CI systems)
>>> will also start using meson, which means that life gets easier for
>>> vmware wrt maintaining the build system, and easier for all developers
>>> who have spent to much of their life waiting for autogen.sh. Then
>>> decommissioning autotools can be a separate topic as Rob suggests,
>>> something we'll do when the world is ready.
>>
>>
>> There's zero overlap between SCons build users and Meson experience, so I
>> don't see how that would work. Who would lead the charge?
>
> It sounds like Dylan and the Intel team are interested in doing the
> meson work. If that's the case, then perhaps you (or other SCons
> users) would be willing to evaluate the result and see if it meets
> your requirements for a SCons replacement?
>
> Kristian
Evaluating is one thing. Actually migrating is another.
Brian already said he'd take a look and evaluate. And I'll help in what
I can. I agree we should all evaluate early.
But I don't think that the proposal of first migrate scons to meson,
then in a second separate step migrate autotools to meson, is viable.
Like I said: there's no knowledge overlap. The two group of people --
the Meson and Windows experts -- will be chasing each other tails. And
all that while, the build will continue to be broken or diverge because
master dev will go on.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 21:16 ` Jose Fonseca
@ 2017-03-24 21:20 ` Jason Ekstrand
2017-03-24 21:34 ` [Mesa-dev] " Rob Clark
2017-03-25 1:25 ` Dylan Baker
2 siblings, 0 replies; 94+ messages in thread
From: Jason Ekstrand @ 2017-03-24 21:20 UTC (permalink / raw)
To: Jose Fonseca
Cc: mesa-dev, Kristian Høgsberg, Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 7966 bytes --]
On Fri, Mar 24, 2017 at 2:16 PM, Jose Fonseca <jfonseca@vmware.com> wrote:
> On 24/03/17 20:08, Kristian Høgsberg wrote:
>
>> On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca <jfonseca@vmware.com>
>> wrote:
>>
>>> On 24/03/17 19:10, Kristian Høgsberg wrote:
>>>
>>>>
>>>> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca <jfonseca@vmware.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On 23/03/17 01:38, Rob Clark wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <
>>>>>>>> alexdeucher@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I guess I'm a little late to the party here, but I haven't had time
>>>>>>>>> to
>>>>>>>>> really let all of this sink in and actually look at meson. It
>>>>>>>>> doesn't
>>>>>>>>> seem so bad with a quick look and I think I could probably sort it
>>>>>>>>> out
>>>>>>>>> when the time came, but there would still be a bit of a learning
>>>>>>>>> curve. While that may not be a big deal at the micro level, I have
>>>>>>>>> concerns at the macro level.
>>>>>>>>>
>>>>>>>>> First, I'm concerned it may discourage casual developers and
>>>>>>>>> packagers. autotools isn't great, but most people are familiar
>>>>>>>>> enough
>>>>>>>>> with it that they can get by. Most people have enough knowledge of
>>>>>>>>> autotools that they can pretty easily diagnose a configuration
>>>>>>>>> based
>>>>>>>>> failure. There are a lot of resources for autotools. I'm not sure
>>>>>>>>> that would be the case for meson. Do we as a community feel we
>>>>>>>>> have
>>>>>>>>> enough meson experience to get people over the hump? Anything that
>>>>>>>>> makes it harder for someone to try a new build or do a bisect is a
>>>>>>>>> big
>>>>>>>>> problem in my opinion.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> One of the things that's prompted this on our side (I've talked this
>>>>>>>> over with
>>>>>>>> other people at Intel before starting), was that clearly we *don't*
>>>>>>>> know
>>>>>>>> autotools well enough to get it right. Emil almost always finds
>>>>>>>> cases
>>>>>>>> were we've
>>>>>>>> done things *almost*, but not quite right.
>>>>>>>>
>>>>>>>> For my part, it took me about 3 or 4 days of reading through the
>>>>>>>> docs
>>>>>>>> and
>>>>>>>> writing the libdrm port to get it right, and a lot of that is just
>>>>>>>> the
>>>>>>>> boilerplate of having ~8 drivers that all need basically the same
>>>>>>>> logic.
>>>>>>>>
>>>>>>>> Next, my bigger concern is for distro and casual packagers and
>>>>>>>>> people
>>>>>>>>> that maintain large build systems with lots of existing custom
>>>>>>>>> configurations. Changing from autotools would basically require
>>>>>>>>> many
>>>>>>>>> of these existing tools and systems to be rewritten and then deal
>>>>>>>>> with
>>>>>>>>> the debugging and fall out from that. The potential decreased
>>>>>>>>> build
>>>>>>>>> time is a nice bonus, but frankly a lot of people/companies have
>>>>>>>>> years
>>>>>>>>> of investment in existing tools.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sure, but we're also not the only ones investigating meson. Gnome is
>>>>>>>> using it
>>>>>>>> already, libepoxy is using it, gstreamer is using it. There are
>>>>>>>> patches
>>>>>>>> for
>>>>>>>> weston (written by Daniel Stone) and libinput (written by Peter
>>>>>>>> Hutterer), there
>>>>>>>> are some other projects in the graphics sphere that people are
>>>>>>>> working
>>>>>>>> on. So
>>>>>>>> even if we as a community decide that meson isn't for us, it's not
>>>>>>>> going
>>>>>>>> away.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It is worth pointing out that it is currently required by no
>>>>>>> component
>>>>>>> of an x.org stack. In the case of libepoxy it was added by a new
>>>>>>> maintainer
>>>>>>> on a new release and even then autoconf remains.
>>>>>>>
>>>>>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>>>>>> currently requires meson to build including gnome and gstreamer.
>>>>>>>
>>>>>>>
>>>>>> but I guess that is conflating two completely different topics..
>>>>>> addition of meson and removal of autotools. It is probably better
>>>>>> that we treat the topics separately. I don't see any way that the two
>>>>>> can happen at the same time.
>>>>>>
>>>>>> The autotools build probably needs to remain for at least a couple
>>>>>> releases, and I certainly wouldn't mind if some of the other desktop
>>>>>> projects took the leap of dropping autotools first (at least then
>>>>>> various different "distro" consumers will have already dealt with how
>>>>>> to build meson packages)
>>>>>>
>>>>>> None of that blocks addition of a meson build system (or what various
>>>>>> developers use day to day)
>>>>>>
>>>>>> BR,
>>>>>> -R
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I tend to disagree. While we can't avoid a transitory period, when we
>>>>> embark on another build system (Meson or something else) I think we
>>>>> should
>>>>> aim at 1) ensure such tool can indeed _completely_ replace at least
>>>>> _one_
>>>>> existing build system, 2) and aim at migration quickly.
>>>>>
>>>>> Otherwise we'll just end up with yet another build system, yet another
>>>>> way
>>>>> builds can fail, with some developers stuck on old build systems
>>>>> because
>>>>> it
>>>>> works, or because the new build system quite doesn't work.
>>>>>
>>>>> And this is from (painful) experience.
>>>>>
>>>>
>>>>
>>>> I agree, adding a meson build system should aim to phase out one of
>>>> the other build systems within one or two release cycles. But (and
>>>> maybe that was Robs point) that doesn't have be autotools. What if we
>>>> phase out scons? It doesn't seem like anybody is really attached to it
>>>> and if meson is as good as scons on windows, then if nothing else
>>>> happens we end up with the same number of build systems. What's more
>>>> likely to happen is that a lot of Linux developers (and CI systems)
>>>> will also start using meson, which means that life gets easier for
>>>> vmware wrt maintaining the build system, and easier for all developers
>>>> who have spent to much of their life waiting for autogen.sh. Then
>>>> decommissioning autotools can be a separate topic as Rob suggests,
>>>> something we'll do when the world is ready.
>>>>
>>>
>>>
>>> There's zero overlap between SCons build users and Meson experience, so I
>>> don't see how that would work. Who would lead the charge?
>>>
>>
>> It sounds like Dylan and the Intel team are interested in doing the
>> meson work. If that's the case, then perhaps you (or other SCons
>> users) would be willing to evaluate the result and see if it meets
>> your requirements for a SCons replacement?
>>
>> Kristian
>>
>
> Evaluating is one thing. Actually migrating is another.
>
> Brian already said he'd take a look and evaluate. And I'll help in what I
> can. I agree we should all evaluate early.
>
>
> But I don't think that the proposal of first migrate scons to meson, then
> in a second separate step migrate autotools to meson, is viable. Like I
> said: there's no knowledge overlap. The two group of people -- the Meson
> and Windows experts -- will be chasing each other tails. And all that
> while, the build will continue to be broken or diverge because master dev
> will go on.
I don't think that's true. I think a decent number of *nix mesa devs will
start using meson as their primary build system. Also, we'll definitely be
using meson in our CI system because it's so much faster and we have a big
workhorse of a build machine. Sure, there will be breakage, but I don't
think it will be one-sided.
[-- Attachment #1.2: Type: text/html, Size: 9123 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 21:16 ` Jose Fonseca
2017-03-24 21:20 ` Jason Ekstrand
@ 2017-03-24 21:34 ` Rob Clark
2017-03-25 1:25 ` Dylan Baker
2 siblings, 0 replies; 94+ messages in thread
From: Rob Clark @ 2017-03-24 21:34 UTC (permalink / raw)
To: Jose Fonseca
Cc: mesa-dev, Kristian Høgsberg, Maling list - DRI developers
On Fri, Mar 24, 2017 at 5:16 PM, Jose Fonseca <jfonseca@vmware.com> wrote:
> On 24/03/17 20:08, Kristian Høgsberg wrote:
>>
>> On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca <jfonseca@vmware.com>
>> wrote:
>>>
>>> On 24/03/17 19:10, Kristian Høgsberg wrote:
>>>>
>>>>
>>>> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca <jfonseca@vmware.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 23/03/17 01:38, Rob Clark wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray <jsg@jsg.id.au> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher
>>>>>>>> <alexdeucher@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I guess I'm a little late to the party here, but I haven't had time
>>>>>>>>> to
>>>>>>>>> really let all of this sink in and actually look at meson. It
>>>>>>>>> doesn't
>>>>>>>>> seem so bad with a quick look and I think I could probably sort it
>>>>>>>>> out
>>>>>>>>> when the time came, but there would still be a bit of a learning
>>>>>>>>> curve. While that may not be a big deal at the micro level, I have
>>>>>>>>> concerns at the macro level.
>>>>>>>>>
>>>>>>>>> First, I'm concerned it may discourage casual developers and
>>>>>>>>> packagers. autotools isn't great, but most people are familiar
>>>>>>>>> enough
>>>>>>>>> with it that they can get by. Most people have enough knowledge of
>>>>>>>>> autotools that they can pretty easily diagnose a configuration
>>>>>>>>> based
>>>>>>>>> failure. There are a lot of resources for autotools. I'm not sure
>>>>>>>>> that would be the case for meson. Do we as a community feel we
>>>>>>>>> have
>>>>>>>>> enough meson experience to get people over the hump? Anything that
>>>>>>>>> makes it harder for someone to try a new build or do a bisect is a
>>>>>>>>> big
>>>>>>>>> problem in my opinion.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> One of the things that's prompted this on our side (I've talked this
>>>>>>>> over with
>>>>>>>> other people at Intel before starting), was that clearly we *don't*
>>>>>>>> know
>>>>>>>> autotools well enough to get it right. Emil almost always finds
>>>>>>>> cases
>>>>>>>> were we've
>>>>>>>> done things *almost*, but not quite right.
>>>>>>>>
>>>>>>>> For my part, it took me about 3 or 4 days of reading through the
>>>>>>>> docs
>>>>>>>> and
>>>>>>>> writing the libdrm port to get it right, and a lot of that is just
>>>>>>>> the
>>>>>>>> boilerplate of having ~8 drivers that all need basically the same
>>>>>>>> logic.
>>>>>>>>
>>>>>>>>> Next, my bigger concern is for distro and casual packagers and
>>>>>>>>> people
>>>>>>>>> that maintain large build systems with lots of existing custom
>>>>>>>>> configurations. Changing from autotools would basically require
>>>>>>>>> many
>>>>>>>>> of these existing tools and systems to be rewritten and then deal
>>>>>>>>> with
>>>>>>>>> the debugging and fall out from that. The potential decreased
>>>>>>>>> build
>>>>>>>>> time is a nice bonus, but frankly a lot of people/companies have
>>>>>>>>> years
>>>>>>>>> of investment in existing tools.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sure, but we're also not the only ones investigating meson. Gnome is
>>>>>>>> using it
>>>>>>>> already, libepoxy is using it, gstreamer is using it. There are
>>>>>>>> patches
>>>>>>>> for
>>>>>>>> weston (written by Daniel Stone) and libinput (written by Peter
>>>>>>>> Hutterer), there
>>>>>>>> are some other projects in the graphics sphere that people are
>>>>>>>> working
>>>>>>>> on. So
>>>>>>>> even if we as a community decide that meson isn't for us, it's not
>>>>>>>> going
>>>>>>>> away.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It is worth pointing out that it is currently required by no
>>>>>>> component
>>>>>>> of an x.org stack. In the case of libepoxy it was added by a new
>>>>>>> maintainer
>>>>>>> on a new release and even then autoconf remains.
>>>>>>>
>>>>>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>>>>>> currently requires meson to build including gnome and gstreamer.
>>>>>>>
>>>>>>
>>>>>> but I guess that is conflating two completely different topics..
>>>>>> addition of meson and removal of autotools. It is probably better
>>>>>> that we treat the topics separately. I don't see any way that the two
>>>>>> can happen at the same time.
>>>>>>
>>>>>> The autotools build probably needs to remain for at least a couple
>>>>>> releases, and I certainly wouldn't mind if some of the other desktop
>>>>>> projects took the leap of dropping autotools first (at least then
>>>>>> various different "distro" consumers will have already dealt with how
>>>>>> to build meson packages)
>>>>>>
>>>>>> None of that blocks addition of a meson build system (or what various
>>>>>> developers use day to day)
>>>>>>
>>>>>> BR,
>>>>>> -R
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I tend to disagree. While we can't avoid a transitory period, when we
>>>>> embark on another build system (Meson or something else) I think we
>>>>> should
>>>>> aim at 1) ensure such tool can indeed _completely_ replace at least
>>>>> _one_
>>>>> existing build system, 2) and aim at migration quickly.
>>>>>
>>>>> Otherwise we'll just end up with yet another build system, yet another
>>>>> way
>>>>> builds can fail, with some developers stuck on old build systems
>>>>> because
>>>>> it
>>>>> works, or because the new build system quite doesn't work.
>>>>>
>>>>> And this is from (painful) experience.
>>>>
>>>>
>>>>
>>>> I agree, adding a meson build system should aim to phase out one of
>>>> the other build systems within one or two release cycles. But (and
>>>> maybe that was Robs point) that doesn't have be autotools. What if we
>>>> phase out scons? It doesn't seem like anybody is really attached to it
>>>> and if meson is as good as scons on windows, then if nothing else
>>>> happens we end up with the same number of build systems. What's more
>>>> likely to happen is that a lot of Linux developers (and CI systems)
>>>> will also start using meson, which means that life gets easier for
>>>> vmware wrt maintaining the build system, and easier for all developers
>>>> who have spent to much of their life waiting for autogen.sh. Then
>>>> decommissioning autotools can be a separate topic as Rob suggests,
>>>> something we'll do when the world is ready.
>>>
>>>
>>>
>>> There's zero overlap between SCons build users and Meson experience, so I
>>> don't see how that would work. Who would lead the charge?
>>
>>
>> It sounds like Dylan and the Intel team are interested in doing the
>> meson work. If that's the case, then perhaps you (or other SCons
>> users) would be willing to evaluate the result and see if it meets
>> your requirements for a SCons replacement?
>>
>> Kristian
>
>
> Evaluating is one thing. Actually migrating is another.
>
> Brian already said he'd take a look and evaluate. And I'll help in what I
> can. I agree we should all evaluate early.
>
>
> But I don't think that the proposal of first migrate scons to meson, then in
> a second separate step migrate autotools to meson, is viable. Like I said:
> there's no knowledge overlap. The two group of people -- the Meson and
> Windows experts -- will be chasing each other tails. And all that while,
> the build will continue to be broken or diverge because master dev will go
> on.
>
Well, I didn't mean to imply that we would remove scons before you
were ready.. as with autotools we can't yank the rug out.
But my theory is that, unlike scons build, since there will be a good
number of devs using meson day to day on *nix, hopefully that
translates into less fixing up the build for windows on your end and
you will prefer to switch ;-)
I think we'll have to evaluate as we go, but covering the windows
build use-case seems like an easier first target than every
corner-case that autotools handles.
BR,
-R
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-23 11:39 ` Emil Velikov
2017-03-23 17:54 ` Dylan Baker
@ 2017-03-25 1:06 ` Kenneth Graunke
1 sibling, 0 replies; 94+ messages in thread
From: Kenneth Graunke @ 2017-03-25 1:06 UTC (permalink / raw)
To: mesa-dev; +Cc: Emil Velikov, Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 1631 bytes --]
On Thursday, March 23, 2017 4:39:50 AM PDT Emil Velikov wrote:
> On 22 March 2017 at 20:10, Dylan Baker <dylan@pnwbakers.com> wrote:
[snip]
> The more frustrating part is that atm autotools build is "bug-free"
> and with meson will have to go through the same route again :-\
"Bug-free" - famous last words :)
It is definitely working a lot better than it used to. I'm grateful
to those who helped make it so (yourself included).
> > For my part, it took me about 3 or 4 days of reading through the docs and
> > writing the libdrm port to get it right, and a lot of that is just the
> > boilerplate of having ~8 drivers that all need basically the same logic.
> >
> Slightly off-topic - 3 days to write the build script for ~10 [nearly]
> identical libraries which do not do anything fancy, seems a lot.
> Which was the most time consuming part ?
As I believe Dylan explained...a lot of his time was spent learning
autotools and its idioms, so he knew how best to translate things.
(Dylan is pretty familiar with CMake, but less so with automake.)
Eric was able to work much more quickly, being already familiar with
the existing build system.
> I'm concerned that we would have to enforce the same time penalty onto
> dozens of developers unfamiliar with meson.
>
> Thanks
> Emil
There's a time penalty figuring out any build system. Most people try
to remain blissfully unaware of it as much as possible. And then, most
tasks people do are pretty simple (adding files, deleting files, etc).
When something complex comes up...it takes time, reading, and sometimes
asking for help...no matter what system you use.
--Ken
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 21:16 ` Jose Fonseca
2017-03-24 21:20 ` Jason Ekstrand
2017-03-24 21:34 ` [Mesa-dev] " Rob Clark
@ 2017-03-25 1:25 ` Dylan Baker
2 siblings, 0 replies; 94+ messages in thread
From: Dylan Baker @ 2017-03-25 1:25 UTC (permalink / raw)
To: Kristian Høgsberg, Jose Fonseca
Cc: mesa-dev, Maling list - DRI developers
[-- Attachment #1.1: Type: text/plain, Size: 2637 bytes --]
Quoting Jose Fonseca (2017-03-24 14:16:13)
>
> Evaluating is one thing. Actually migrating is another.
>
> Brian already said he'd take a look and evaluate. And I'll help in what
> I can. I agree we should all evaluate early.
>
>
> But I don't think that the proposal of first migrate scons to meson,
> then in a second separate step migrate autotools to meson, is viable.
> Like I said: there's no knowledge overlap. The two group of people --
> the Meson and Windows experts -- will be chasing each other tails. And
> all that while, the build will continue to be broken or diverge because
> master dev will go on.
>
>
> Jose
https://github.com/dcbaker/mesa-demos wip/meson
I've blindly ported some of the windows bits but have no way to test them, so
you can either delete the lot and go from scratch or see what's left to fix (the
wgl folder, for example). I have not implemented much of the windows or apple
logic in the root CMakeLists.txt, so hopefully that's useful for your purposes.
That branch also builds on my Archlinux machine, but not on debian due to
difference in the way they package freeglut I just ran out of time today. For
the record, I started at about 12:00, and finished at about 17:00 with a 1 hour
lunch in there. So about 3 hours to get a mostly working build. I'm going to try
to iron out the debian and travis issues either over the weekend or next week.
There is one difference, because ninja is non-recursive some targets would have
the same name and collide, so I've renamed some of the not installed binaries. I
believe that a non-recursive make (such as one generated by cmake) would have
the same problem. meson doesn't seem to have a method to rename the target, but
it's also a bit of an odd corner to build multiple binaries with the same name
that are both not installed and are for people (not automated build steps) to
use.
I also have a not quite working .travis.yml on that branch.
I'm also planning to get a mesa RFC sent out early next week once I get i965 and
llvmpipe building.
If we merge mesa we (Intel) will move to using meson as our primary build system
in CI (the one we run tests against) as soon as it's ready. Building mesa is
quite slow for us considering the power of our build hardware, and meson should
help with that. We'll continue to build autotools much the way we do scons now,
as a secondary "buildtest" only target.
Dylan
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[-- Attachment #1.2: signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEUwPMqo/+5aFHLzU4CJ4WlhQGiO8FAljVxxUACgkQCJ4WlhQG
iO8B+AgAhHcc5Qjm09mAMXe07nkYiKne7Ha5+wF30r97G5PEXEfM5pGZf0tolhSV
gPKSudyFcN/ChDRLuNLLhytPyeknqIV36gYNgP13+ehSfOtrQFddzKIEdAFmEqQO
vbI3x2tbPN989lrtU+JuGeDayjehuPZbgLuh9o/SwWPgOw9msQxf7aokIGZMN1mI
sEz14iNKOZkd0fo656BL4WROYzgo2O2BWMZLZ1L+1D1Bbo9dYWX5xJiSsCTJAT1A
b9zu/pWlQHpZHK5DCygs98O2sCi1ef4qHTqWY1yV50PLEyJoCwb08FsP98vFppPU
Wi87HSelnzbRwn9MRW0hzua3ZlJrnA==
=UYyB
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/plain, Size: 157 bytes --]
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 15:47 ` Jose Fonseca
@ 2017-03-25 20:15 ` Rob Clark
0 siblings, 0 replies; 94+ messages in thread
From: Rob Clark @ 2017-03-25 20:15 UTC (permalink / raw)
To: Jose Fonseca; +Cc: ML mesa-dev, ML dri-devel
On Fri, Mar 24, 2017 at 11:47 AM, Jose Fonseca <jfonseca@vmware.com> wrote:
>
> Like I said in another email, maybe mesademos is a good way to get our feet
> wet.
jfwiw, I decided to figure out what this meson stuff is all about, and
converted kmscube (after adding an optional bit for video-cube, to
make it *slightly* more interesting).. it's (a) fast and (b) not hard
to figure out
https://lists.freedesktop.org/archives/mesa-dev/2017-March/149603.html
BR,
-R
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-24 20:44 ` [Mesa-dev] " Chad Versace
@ 2017-03-28 16:59 ` Emil Velikov
2017-03-28 23:19 ` Timothy Arceri
0 siblings, 1 reply; 94+ messages in thread
From: Emil Velikov @ 2017-03-28 16:59 UTC (permalink / raw)
To: Chad Versace, Matt Turner, Emil Velikov, ML mesa-dev, ML dri-devel
Hi Chad,
On 24 March 2017 at 20:44, Chad Versace <chadversary@chromium.org> wrote:
> On Tue 21 Mar 2017, Matt Turner wrote:
>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> > On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
>> >> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>
>> >>> These projects have been getting closer to upstream and "forcing" the
>> >>> extra obstacle is effectively giving them the middle finger.
>> >>
>> >> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>> >>
>> > Can we stop with the GCC thing ? Can we point to a place where we want
>> > to use feature A introduced with GCC B and we don't ?
>>
>> Are you freaking serious?!
>>
>> This happens *all* the time. It happened like two days ago with commit
>> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
>> happened at least once in the previous month, and every month before
>> that.
>
> More examples:
>
> - Jason and I wanted to use C11 generic expressions (that's what the
> C11 spec calls them) in anvil, but old GCC => !C11.
>
[snip]
>
> freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | vulkan/anv_device.c:697:4: error: initializer element is not constant
> freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
> freenode.#dri-devel.log-2017-03-16 11:07:23 | imirkin_ | anyone seen this? i'm on HEAD
> freenode.#dri-devel.log-2017-03-16 11:13:50 | vsyrjala | yep. gcc-4.9 strikes again?
> freenode.#dri-devel.log-2017-03-16 11:14:54 | imirkin_ | i'm definitely using gcc-4.9
> freenode.#dri-devel.log-2017-03-16 11:15:16 | vsyrjala | that '(VkExtent3D)' looks very much pointless there
> freenode.#dri-devel.log-2017-03-16 11:15:56 | imirkin_ | 4.9.4 as it happens, which is the "stable" gcc on gentoo
> freenode.#dri-devel.log:2017-03-16 11:18:04 | vsyrjala | looks like chadv broke it
As mentioned elsewhere - if major stakeholders of $driver want to bump
the requirement, please do.
As an example: st/nine requires GCC 4.6 and st/clover GCC 4.7 for a
very long time.
Thanks
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [RFC libdrm 0/2] Replace the build system with meson
2017-03-28 16:59 ` Emil Velikov
@ 2017-03-28 23:19 ` Timothy Arceri
0 siblings, 0 replies; 94+ messages in thread
From: Timothy Arceri @ 2017-03-28 23:19 UTC (permalink / raw)
To: Emil Velikov, Chad Versace, Matt Turner, ML mesa-dev, ML dri-devel
On 29/03/17 03:59, Emil Velikov wrote:
> Hi Chad,
>
> On 24 March 2017 at 20:44, Chad Versace <chadversary@chromium.org> wrote:
>> On Tue 21 Mar 2017, Matt Turner wrote:
>>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>> On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
>>>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>
>>>>>> These projects have been getting closer to upstream and "forcing" the
>>>>>> extra obstacle is effectively giving them the middle finger.
>>>>>
>>>>> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>>>>>
>>>> Can we stop with the GCC thing ? Can we point to a place where we want
>>>> to use feature A introduced with GCC B and we don't ?
>>>
>>> Are you freaking serious?!
>>>
>>> This happens *all* the time. It happened like two days ago with commit
>>> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
>>> happened at least once in the previous month, and every month before
>>> that.
>>
>> More examples:
>>
>> - Jason and I wanted to use C11 generic expressions (that's what the
>> C11 spec calls them) in anvil, but old GCC => !C11.
>>
> [snip]
>>
>> freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | vulkan/anv_device.c:697:4: error: initializer element is not constant
>> freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
>> freenode.#dri-devel.log-2017-03-16 11:07:23 | imirkin_ | anyone seen this? i'm on HEAD
>> freenode.#dri-devel.log-2017-03-16 11:13:50 | vsyrjala | yep. gcc-4.9 strikes again?
>> freenode.#dri-devel.log-2017-03-16 11:14:54 | imirkin_ | i'm definitely using gcc-4.9
>> freenode.#dri-devel.log-2017-03-16 11:15:16 | vsyrjala | that '(VkExtent3D)' looks very much pointless there
>> freenode.#dri-devel.log-2017-03-16 11:15:56 | imirkin_ | 4.9.4 as it happens, which is the "stable" gcc on gentoo
>> freenode.#dri-devel.log:2017-03-16 11:18:04 | vsyrjala | looks like chadv broke it
>
> As mentioned elsewhere - if major stakeholders of $driver want to bump
> the requirement, please do.
> As an example: st/nine requires GCC 4.6 and st/clover GCC 4.7 for a
> very long time.
That seems fine for optional state trackers but seems like a bad idea to
encourage that for major drivers. It's likely to lead to features being
used in common code.
I'm not actually against this, just pointing out the obvious.
Hopefully VMWARE will migrate to something newer at some stage. That
seems to be the major blocker at this point in time.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
^ permalink raw reply [flat|nested] 94+ messages in thread
end of thread, other threads:[~2017-03-28 23:19 UTC | newest]
Thread overview: 94+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-16 21:25 [RFC libdrm 0/2] Replace the build system with meson Dylan Baker
2017-03-16 21:25 ` [RFC libdrm 1/2] Port build system to meson Dylan Baker
2017-03-16 21:25 ` [RFC libdrm 2/2] remove autotools build Dylan Baker
2017-03-16 21:32 ` [RFC libdrm 0/2] Replace the build system with meson Ilia Mirkin
2017-03-16 21:57 ` Dylan Baker
2017-03-17 10:05 ` Neil Armstrong
2017-03-16 22:36 ` Marek Olšák
2017-03-16 23:11 ` Dylan Baker
2017-03-17 1:53 ` Marek Olšák
2017-03-17 4:15 ` Dylan Baker
2017-03-17 21:18 ` Marek Olšák
2017-03-22 17:26 ` Jose Fonseca
2017-03-22 17:50 ` [Mesa-dev] " Marek Olšák
2017-03-16 23:35 ` Emil Velikov
2017-03-17 0:21 ` Dylan Baker
2017-03-17 0:41 ` Emil Velikov
2017-03-17 2:03 ` Jason Ekstrand
2017-03-17 2:28 ` Brian Paul
2017-03-22 17:59 ` Jose Fonseca
2017-03-22 20:57 ` [Mesa-dev] " Dylan Baker
2017-03-22 22:02 ` Rob Clark
2017-03-22 22:15 ` Eric Anholt
2017-03-22 22:33 ` Dylan Baker
2017-03-24 14:03 ` Jose Fonseca
2017-03-24 14:22 ` [Mesa-dev] " Daniel Stone
2017-03-24 15:47 ` Jose Fonseca
2017-03-25 20:15 ` [Mesa-dev] " Rob Clark
2017-03-24 16:23 ` Bas Nieuwenhuizen
2017-03-17 4:12 ` Dylan Baker
2017-03-17 6:02 ` Jonathan Gray
2017-03-20 13:55 ` [Mesa-dev] " Emil Velikov
2017-03-20 18:30 ` Matt Turner
2017-03-20 19:39 ` [Mesa-dev] " Emil Velikov
2017-03-20 21:28 ` Timothy Arceri
2017-03-20 21:38 ` Jason Ekstrand
2017-03-21 5:00 ` Jonathan Gray
2017-03-21 16:00 ` Matt Turner
2017-03-23 12:23 ` Jonathan Gray
2017-03-23 18:31 ` Emil Velikov
2017-03-21 15:57 ` [Mesa-dev] " Matt Turner
2017-03-21 17:16 ` Emil Velikov
2017-03-21 18:06 ` Matt Turner
2017-03-21 18:56 ` [Mesa-dev] " Emil Velikov
2017-03-21 19:08 ` Jason Ekstrand
2017-03-21 19:10 ` [Mesa-dev] " Matt Turner
2017-03-22 17:16 ` Emil Velikov
2017-03-24 20:59 ` Chad Versace
2017-03-24 20:44 ` [Mesa-dev] " Chad Versace
2017-03-28 16:59 ` Emil Velikov
2017-03-28 23:19 ` Timothy Arceri
2017-03-21 5:10 ` Jonathan Gray
2017-03-21 16:11 ` [Mesa-dev] " Matt Turner
2017-03-24 16:58 ` randyf
2017-03-20 19:29 ` Rob Clark
2017-03-21 14:44 ` Jani Nikula
2017-03-21 15:13 ` Grazvydas Ignotas
2017-03-21 15:15 ` Ilia Mirkin
2017-03-21 16:16 ` Dylan Baker
2017-03-21 16:22 ` Dylan Baker
2017-03-22 4:23 ` [Mesa-dev] " Jonathan Gray
2017-03-22 8:24 ` Jani Nikula
2017-03-22 21:05 ` Dylan Baker
2017-03-23 8:13 ` Jani Nikula
2017-03-21 16:50 ` Kai Wasserbäch
2017-03-21 17:34 ` Dylan Baker
2017-03-21 18:36 ` [Mesa-dev] " Kai Wasserbäch
2017-03-21 21:16 ` Dylan Baker
2017-03-22 16:40 ` Alex Deucher
2017-03-22 17:07 ` Rob Clark
2017-03-22 20:10 ` [Mesa-dev] " Dylan Baker
2017-03-22 21:48 ` Rob Clark
2017-03-23 21:56 ` Greg Hackmann
2017-03-23 22:14 ` Colin Cross
2017-03-23 23:56 ` Dylan Baker
2017-03-24 0:03 ` [Mesa-dev] " Colin Cross
2017-03-24 16:54 ` Dylan Baker
2017-03-23 1:18 ` [Mesa-dev] " Jonathan Gray
2017-03-23 1:38 ` Rob Clark
2017-03-24 13:42 ` Jose Fonseca
2017-03-24 17:13 ` Dylan Baker
2017-03-24 17:51 ` Eric Anholt
2017-03-24 18:34 ` [Mesa-dev] " Daniel Stone
2017-03-24 19:10 ` Kristian Høgsberg
2017-03-24 19:44 ` Jose Fonseca
2017-03-24 20:08 ` Kristian Høgsberg
2017-03-24 21:16 ` Jose Fonseca
2017-03-24 21:20 ` Jason Ekstrand
2017-03-24 21:34 ` [Mesa-dev] " Rob Clark
2017-03-25 1:25 ` Dylan Baker
2017-03-24 21:09 ` [Mesa-dev] " Rob Clark
2017-03-23 11:39 ` Emil Velikov
2017-03-23 17:54 ` Dylan Baker
2017-03-25 1:06 ` Kenneth Graunke
2017-03-22 22:30 ` [Mesa-dev] " Eric Anholt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.