[HN Gopher] Meson Build System 1.0
___________________________________________________________________
Meson Build System 1.0
Author : TangerineDream
Score : 79 points
Date : 2022-12-23 18:41 UTC (4 hours ago)
(HTM) web link (mesonbuild.com)
(TXT) w3m dump (mesonbuild.com)
| malkia wrote:
| Are there any stories/articles on why people chose meson, over
| say CMake (or others)? I do like meson much more than CMake for
| sure, sane syntax and all.
| hawski wrote:
| For me a little disadvantage of Meson is that it is implemented
| in Python. With my interest in minimal systems and
| bootstrapping I would hope that it would get to be
| reimplemented in something easier to bootstrap or (maybe
| preferable) Python environment/version problems would get
| solved before the wider adoption. I understand, that it may not
| be as much a problem for others.
| tristan957 wrote:
| You should read the blog post you are commenting on.
| aurelian15 wrote:
| For what it is worth, there is Muon, a third-party
| implementation of Meson written in C99 [1]. Haven't used it
| myself yet, though Muon has been in steady development over
| the last few years, and the developers claim that they
| implement the vast majority of the Meson core features.
|
| [1] https://sr.ht/~lattis/muon/
| endgame wrote:
| Bootstrapping is something I care about a lot, too, and keeps
| me on GNU Autotools. Have you found any other options?
| winter_squirrel wrote:
| [dead]
| tristan957 wrote:
| Muon[1] is a reimplementation of Meson in C. You should
| really read the blog post that you are commenting on.
|
| 1: https://sr.ht/~lattis/muon/
| mdaniel wrote:
| > muon analyze - a static analyzer for meson.build files.
| Capable of doing type inference, checking unused
| variables, undeclared variables, etc.
|
| Whoa, that's fancy! That whole project seems neat, thanks
| for pointing it out
| ironman1478 wrote:
| I'll say that I use Meson primarily due to the syntax. It's
| significantly easier to read, which leads to easier
| maintainability. For example, we started a new project and I
| wrote the build scripts in Meson. Then a team member had to
| come in an extend it and they were able to add onto the build
| with basically no assistance. I've never had this experience
| with CMake.
|
| I also really like wrapDB. It's made it easy to adopt some
| common libraries, like fmt.
|
| I'll say though, this projects I've worked on that use mesonDB
| were relatively small and encroaching on medium size projects.
| For large projects with complicated builds, I would've chosen
| something like bazel (and it's what our company has done).
| majoe wrote:
| I'm using meson, since I started a new job a few months ago and
| so far I find it to be absolutely delightful, especially compared
| to cmake.
|
| There is almost always only one certain way to do something,
| which makes it easy to learn, but sometimes frustrating to use,
| if you're not doing it the "meson way".
|
| I also like the .wrap file mechanism to manage dependencies. It's
| simple, yet powerful enough for our small team and so far we
| didn't have the need to use a more complex solution.
| lazypenguin wrote:
| 2019 was the last time I looked into the CMake vs. Meson debate
| and while Meson looked 100% saner, cleaner, etc. the network
| effects of most of the popular C++ libraries using CMake made me
| end up picking CMake. I'd be curious how the landscape is today
| but I now have stockholm syndrome with CMake especially using
| vcpkg.
| einpoklum wrote:
| I looked at these two, not just 2019 and meson looked much more
| difficult to use, and super-confusing, to the person who needs
| to perform the build. In terms of writing CMake vs Meson - I've
| only written CMake, but I've tried to look into meson files to
| understand how to tweak something, and it was hard for me.
| loup-vaillant wrote:
| I happen to have had the more neutral perspective of being a
| beginner at both.
|
| Meson was easier to pick up. Not nearly as easy as I feel it
| should be (the idea of a _meta_ build system when you target
| a single platform has always struck me as insane), but still
| easier than CMake.
| tristan957 wrote:
| CMake is also a meta build system, so I don't understand
| your point. Meson targets many platforms, some better than
| others.
|
| * Visual Studio Projects * Ninja * XCode
| tristan957 wrote:
| Meson integrates fairly well with CMake. The CMake support is
| maintained by a student however. Said student has been busy for
| a bit, so some bug reports and feature requests have sat
| dormant. My needs are 100% met. A ton of popular C++ libraries
| exist within Meson's WrapDB however.
| FpUser wrote:
| I have no knowledge of CMake other than that of a very
| superficial user. Still I think due to critical mass unless we
| have something truly ingenuous it is probably better to keep
| adding missing features to CMake than create other tools from a
| scratch.
| IshKebab wrote:
| I agree. I looked into Meson back when I had to use CMake and
| it is definitely an order of magnitude saner... But it's still
| basically the same as CMake and it lacks the enormous mindshare
| or CMake.
|
| If I was going to use something that wasn't CMake I would use
| something that fixed _lots_ of problems - Bazel or its ilk -
| not something that was just CMake but less fugly.
| tristan957 wrote:
| You are free to do that, but I am going to continue using Meson
| since it is so much better than CMake will ever be. The syntax
| is actually readable and familiar.
| oldgradstudent wrote:
| Meson still won't have user defined functions, and gives a bad
| excuse:
|
| > Meson does not currently support user-defined functions or
| methods. The addition of user-defined functions would make Meson
| Turing-complete which would make it harder to reason about and
| more difficult to integrate with tools like IDEs.
|
| No, user-defined functions won't make Meson Turing-complete as
| long as recursion is not allowed.
|
| User defined functions make it easier to encapsulate complicated
| build logic and reuse it.
| tristan957 wrote:
| If the only reason to use CMake is user-defined functions, I
| see no real reason to use it. The gains in readability of Meson
| are far and beyond the gains of user-defined functions in my
| opinion. I maintain a large open source library and haven't
| once felt the need for user-defined functions.
| oldgradstudent wrote:
| The excuse is still wrong, and indicates complete
| misunderstanding of what Turing-complete means.
|
| I write plugins for a large, well known application.
|
| Building the plugin is a complicated multi stage process with
| many dependencies.
|
| I've spent a lot of time understanding the process
| (undocumented, only VS and Xcode project files are provided
| in the SDK).
|
| I now have a single function call to create each plugin.
| tristan957 wrote:
| What is hard about the following? #
| project/meson.build project_plugin_dep =
| declare_dependency( include_directories:
| plugin_includes, compile_args: plugin_c_args
| ) # plugin/meson.build, repeated for each
| plugin shared_module( 'plugin',
| 'plugin.c', dependencies: project_plugin_dep
| )
|
| Without having seen what your user-defined function does,
| this is the best equivalent that I can come up with. If
| your plugins exist out of tree, then Meson can consume a
| pkg-config file. Postgres is slowly moving to Meson and
| uses out of tree plugins.
| palata wrote:
| Is it really a bad excuse, or is it a polite way to say "Why
| the hell do you need user-defined functions?". At least that's
| how I would say it myself.
| oldgradstudent wrote:
| The reason you need functions anywhere else. Encapsulate
| complicated build logic and reuse it.
| hulitu wrote:
| I hate the world today. Every program needs its own build system.
| /s
| einpoklum wrote:
| In my experience, CMake seems to be more capable and easier to
| work with, both for the package author and for the person trying
| to build it. Also, more flexible in terms of how
| projects/packages depend on each other.
|
| Now CMake is certainly not great; it has a lot of warts and
| baggage; and some functionality is _not_ easy to use, like
| installation (you need a good hour of explanation to make heads
| from tails with that, and then you're supposed to write 4 or 5
| different CMake commands even for the simple use-case of "just
| install my damn plain-vanilla library"). But I'll choose it over
| meson any day of the week, and so would my users (i.e. the people
| who download and build my packages).
| jeltz wrote:
| As someone who usually builds things I disagree. I think
| autotools is easiest followed by Meson and with the most
| annoying build system being CMake. On the other hand when I
| have to write build scripts I think Meson is best followed by
| CMake and then autotools. I feel Meson is a good compromise
| between maintainer needs and end user (the guy who build the
| project) needs.
| tristan957 wrote:
| Can you give any reasons for being "more capable and easier to
| work with?" I don't see how it is easier for users since as far
| as I am aware pkg-config files are an after-thought in CMake
| and options are all over the place (no equivalent of b_lto,
| default_libary, b_sanitize, etc.) so you have to learn about
| each project's non-standard equivalent options.
|
| What is hard about the following for users?
| meson setup build <build options...> ninja -C build
| ninja -C build install
| wirrbel wrote:
| I really like automake and autoconf it's not like I don't know
| the shortcomings but with a routine (and good templates) it
| just works and works and works
| bonzini wrote:
| I used to like autotools a lot and even contributed to them,
| but honestly since I started using Meson there has been no
| going back.
|
| It's not perfect and I do have three-four pet peeves that I
| hate about Meson, but they are more than offset by the
| overall ease of use and a feature set that matches pretty
| much what I need from a build system.
| IshKebab wrote:
| Autotools is the most portable build system... if you ignore
| the most popular desktop OS in the world.
| einpoklum wrote:
| 1. How well is CUDA supported there, for example?
|
| 2. What about when your users are on Windows?
|
| 3. How easy is it to combine autotools projects?
| hackerbrother wrote:
| Why do many C/C++ projects have both Meson and Ninja commands in
| their install instructions? Shouldn't only one be necessary?
| Un1corn wrote:
| Meson generates Ninja files. At first, you were supposed to run
| ninja after Meson yourself but modern Meson support meson
| compile which calls ninja under the hood
| hackerbrother wrote:
| Yup, and Wikipedia says it very clearly too. Thanks!
|
| > In contrast to Make, Ninja lacks features such as string
| manipulation, as Ninja build files are not meant to be
| written by hand. Instead, a "build generator" should be used
| to generate Ninja build files. Gyp, CMake, Meson, and gn[9]
| are popular build management software tools which support
| creating build files for Ninja.
| bonzini wrote:
| Meson looks at the system (finds compilers and dependencies,
| mostly) and prepares a build directory with a build.ninja file
| in it (and possibly other files).
|
| Once the build directory is ready you compile with ninja, there
| is a wrapper "meson compile" but it's kinda pointless because
| it's longer and doesn't provide any extra functionality.
___________________________________________________________________
(page generated 2022-12-23 23:00 UTC)