* [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: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-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 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 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: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: [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-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-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: [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: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: [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: [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: [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 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: [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: [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 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: [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 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-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: [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: [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-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 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 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 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: [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-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-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-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
* 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: [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: [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: [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: [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: [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: [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-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: [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: [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 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: [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: [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: [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-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 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 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-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-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-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-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: [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-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 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: [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: [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-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: [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
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.