liburing
liburing copied to clipboard
axboe
add meson build system
Neither the commit nor the pull request has any details on what meson is and why this is a valuable addition. I'm generally not opposed to including things that make it easier for folks to integrate, but there's an associated cost with adding another build system. Hence I'd really like to get some justification for why this is useful and necessary.
Sorry, I guess meson is not (yet) well known among kernel people.
why this is useful
$ scc
───────────────────────────────────────────────────────────────────────────────
Language Files Lines Blanks Comments Code Complexity
───────────────────────────────────────────────────────────────────────────────
C 106 23479 3552 1000 18927 3638
Meson 8 384 23 0 361 5
C Header 4 1088 139 181 768 15
Makefile 4 455 58 2 395 2
Shell 4 586 69 81 436 56
License 3 558 94 0 464 0
Autoconf 2 19 2 3 14 0
C++ 1 45 8 5 32 6
YAML 1 22 0 0 22 0
gitignore 1 124 6 0 118 0
───────────────────────────────────────────────────────────────────────────────
Total 134 26760 3951 1272 21537 3722
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop $678,328
Estimated Schedule Effort 11.867553 months
Estimated People Required 5.078021
───────────────────────────────────────────────────────────────────────────────
Processed 567943 bytes, 0.568 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────
and necessary.
I certainly wouldn't call it "necessary". It surely is more common for desktop stuff (gnome, x11, mesa), but some low level projects (systemd, qemu) have adopted it too. Since liburing is a rather small codebase, the speed and simplicity advantages in this case are not so huge as with other projects:
- It provides some nice features (e.g. out-of-source builds) out of box, that one would need to implement in shell.
- Other projects that use meson could integrate liburing easily into their build system by using meson's subproject() functionality.
- Meson provides some useful editor/IDE integration, e.g. by generating compile_commands.json for clangd.
- Distro maintainers I could image, wouldn't mind having most of their packages built with a "standard" build system.
Can you add that description to the actual commit message? And also please remember to add your Signed-off-by line to the bottom of the commit as well.
I'm not familiar with Meson, but just wanted to mention that I find the existing make based build process really nice.
I have a two branches introducing meson as a build system on top of master as well as liburing-2.0 containing the suggested changes from @ntonnaett. The branch based on liburing-2.0 is submitted to be included into the meson wrapdb so it can be easily consumed using meson wrap.
@eszlari if you are still interested in this PR feel free to use my changes otherwise I would open a new pull request with my branch.
meson file for each folder is probably too much (I mean for include dir mostly).
meson file for each folder is probably too much (I mean for include dir mostly).
What is the reason to drop the include/meson.build file? To reduce the diff because someone complained in #438?
For anyone interested I updated the meson build code for liburing-2.2 at fischerling/liburing/meson-liburing-2.2 and submitted a pull request to update the version included in the meson wrapdb.
To reduce the diff because someone complained in https://github.com/axboe/liburing/pull/438?
for example, but I suppose the smallest diff it's better anyway, I believe Meson Build is not a Makefile replacement as is and creating a new file on each level is legacy. This PR here since 2021. Will be good to upstream it, and comments from CMake friends do not help us. :( @axboe please reconsider this, because using Meson in Dockerfile or during RPM/DEB/Ebuild is much clear and simpler. It should help package maintainers.
included in the meson wrapdb.
I prefer the idea of upstreaming current PR instead do it for wrapdb.
included in the meson wrapdb.
I prefer the idea of upstreaming current PR instead do it for wrapdb.
I also prefer having the meson changes upstream. But since this PR has no real activity or interest, using the meson wrapdb solves all my problems by making liburing easy consumable from other meson projects.
@axboe Do you consider changing the build system at all? Should I open a new PR with the meson changes based on liburing-2.2?
Do you consider changing the build system at all? Should I open a new PR with the meson changes based on liburing-2.2?
It's not that I'm vehemently against changing the build system, but my main issue is that it's something that I have to support. And I don't know anything about meson, but to be honest, I know very little about make either but enough to fake it.
On top of that, then you get people that take that side very seriously, and then I end up in a situation where everybody wants their favorite build system added. And that is certainly a path I'm not interested in at all. Whatever we end up doing, a single build system that is maintainable and broadly usable by everyone is important. The latter really is key, too.
The hand rolled configure and basic makefiles are definitely a bit archaic, but It Works and is simpler to build and grok for everyone. Which is why I haven't changed it so far.
Guess I didn't answer the specific question - yes, let's see a meson patch for the current branch and we can take a closer look at this.
And further, I'm not at all interested in a dump-and-run build system conversion. If you submit one and are asking for it to be merged, I fully expect YOU to know be the build system maintainer for liburing. It's a small project and should not be a lot of work, but you need to put up with my stupid questions and have time to devote to it. Initially I'm sure a bit more than in the long run, but you are on the hook for that. That means I need a way to contact you that isn't github (as that's purely a secondary thing for me), eg I need to know who you are and what your email is, and others do too.
Hence if you do go forward with this, make sure this information is in the git tree somehow. Thanks!
I would also be happy to maintain or help maintain a meson build system going forward.
'-Wno-unused-parameter',
'-Wno-sign-compare',
'-fomit-frame-pointer',
Hardcoding warning and optimistation flags is alway bad practice.
It would be good to update version in PR to be able to test that with last release.
If I am not alone maintaining and being responsible for the meson code as @tp-m comment shows, I would also happily maintain and provide help for a build system based on meson.
I also can help with Meson.
And I don't know anything about meson
luckily, the Meson is a very simple build system and one or two days is enough to start working with.