On 27.07.2022 12:21, Bart Van Assche wrote: > On 7/27/22 08:27, Florian Fischer wrote: > > 11 files changed, 619 insertions(+), 4 deletions(-) > > To me this diffstat tells me that this patch series adds a lot of complexity > instead of removing complexity. That's because Jens wants to keep both build systems in the repository. .github/workflows/build.yml | 44 +++++-- .gitignore | 2 + Makefile | 84 ------------ Makefile.common | 6 - Makefile.quiet | 11 -- configure | 467 ----------------------------------------------------------------- examples/Makefile | 41 ------ examples/meson.build | 19 +++ man/meson.build | 116 ++++++++++++++++ meson.build | 119 +++++++++++++++++ meson_options.txt | 14 ++ src/Makefile | 87 ------------ src/include/liburing/compat.h.in | 7 + src/include/liburing/meson.build | 51 +++++++ src/include/meson.build | 3 + src/meson.build | 28 ++++ test/Makefile | 238 --------------------------------- test/meson.build | 219 +++++++++++++++++++++++++++++++ 18 files changed, 609 insertions(+), 947 deletions(-) This is what the diffstat could look like if we would remove the old build system. > That leaves me wondering what the advantages of this patch series are? The most notable advantages of having a meson-based build system are highlighted in the cover mail. For me the by far most important feature and why I maintained the initial meson code from 2021 is the interoperability with other meson-based projects. Everything needed to consume liburing is to have a wrap file for liburing in your subprojects directory and use it in your meson build logic. subprojects/liburing.wrap: [wrap-git] url = https://git.kernel.dk/liburing revision = master And use the following lines in your meson code: liburing_proj = subproject('emper') liburing_dep = liburing_proj/get_variable('uring') # somehow use the dependency object --- Florian Fischer
