12 ms·

Meson Build System 1.0

150 points by TangerineDream 4y ago

malkia 4y ago
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 4y ago
  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.
  - aurelian15 4y ago
    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/ https://sr.ht/~lattis/muon/
    - mdaniel 4y ago
      I was going to try replacing the KeePassXC build (which is one of the more complicated CMake builds I've had hand-to-hand with) to see what that experience would be like, but they report all the Qt flavors are unsupported: https://muon.build/releases/edge/docs/status.html https://muon.build/releases/edge/docs/status.html I'm aware I could just vanilla Meson but I was specifically interested in kicking the tires on the dbg in Muon since CLion just recently added debugging to CMake and I wanted to compare and contrast
  - endgame 4y ago
    Bootstrapping is something I care about a lot, too, and keeps me on GNU Autotools. Have you found any other options?
    - winter_squirrel 4y ago
      [dead]
    - tristan957 4y ago
      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/ https://sr.ht/~lattis/muon/
      - mdaniel 4y ago
        > 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
        tristan957 4y ago
        It even has a debugger and an auto formatter. Meson is getting an auto formatter in https://github.com/mesonbuild/meson/pull/10971 https://github.com/mesonbuild/meson/pull/10971.
        chombier 4y ago
        > type inference This means muon can fairly easily implement user-defined functions without making the language Turing complete. If they did this I would happily (re)consider switching from CMake.
  - tristan957 4y ago
    You should read the blog post you are commenting on.
    - hawski 4y ago
      What do you mean? It is not a blog post, those are release notes, that do not seem to me to be relevant to my comment.
- ironman1478 4y ago
  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).
- germandiago 4y ago
  In Medium I posted some years back this, it is four articles: https://www.google.com/url?q=https://germandiagogomez.medium.com/getting-started-with-meson-build-system-and-c-83270f444bee&sa=U&ved=2ahUKEwi_5vaV7JH8AhWIF4gKHaKxBtEQFnoECAYQAg&usg=AOvVaw2jKPxwkTlvc-jrUFJ6bX5W https://www.google.com/url?q=https://germandiagogomez.medium...
  - malkia 4y ago
    Thank you!
- germandiago 4y ago
  htttps://germandiagogomez.medium.com/getting-started-with-meson-build-system-and-c-83270f444bee&sa=U&ved=2ahUKEwi_5vaV7JH8AhWIF4gKHaKxBtEQFnoECAYQAg&usg=AOvVaw2jKPxwkTlvc-jrUFJ6bX5W
  - malkia 4y ago
    Thanks! I'll check it out!
    - malkia 4y ago
      Seems like this was the right link - https://germandiagogomez.medium.com/getting-started-with-meson-build-system-and-c-83270f444bee https://germandiagogomez.medium.com/getting-started-with-mes...
lazypenguin 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      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
      - MBCook 4y ago
        Not the GP but I read their point not as pro-Meson but more that both Meson and CMake feel like overkill for a single platform/architecture project.
        tristan957 4y ago
        If you are the only contributor, targeting one compiler, on one platform, then yep, I could see how this might be overkill.
hulitu 4y ago
I hate the world today. Every program needs its own build system. /s
einpoklum 4y ago
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).
- wirrbel 4y ago
  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 4y ago
    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.
  - einpoklum 4y ago
    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?
    - wirrbel 4y ago
      1. dunno never used CUDA. Pretty sure you can hack something together but I am the first to admit that it will be a bumpy ride if you start from 0 2. depends on what you are building. My users run WSL so essentially Linux user space. 3. are you asking for interdependencies? It works in principle I would say, for an elaborate foolproof setup I would anyway use bazel or buck in such a situation.
FpUser 4y ago
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 4y ago
  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 4y ago
  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.
hackerbrother 4y ago
Why do many C/C++ projects have both Meson and Ninja commands in their install instructions? Shouldn't only one be necessary?
- Un1corn 4y ago
  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 4y ago
    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 4y ago
  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.
- germandiago 4y ago
  meson compile will invoke the backend used.
oldgradstudent 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      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.
majoe 4y ago
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.
synergy20 4y ago
Played with Meson for one hour and bailed out, will stay with makefile/cmake. I especially like cmake that can convert pkg-config from -I header.h to -isystem header.h.
- bonzini 4y ago
  Like "dependency(..., include_type: 'system')"?
  - synergy20 4y ago
    thanks, 1 hour was obviously enough to figure this out. time is just tight and it's hard for new things like meson or the rest of 20 different build systems to stand out, unless they're really simple/quick to take on I guess.
    - bonzini 4y ago
      To be honest I just googled "Meson dependency isystem" and any of the first few results would have given the answer (I used the third which was a bug report). That said, using isystem for dependencies is a relatively advanced concept, not something I would do in the first hour of trying Meson.
      - ablob 4y ago
        I did not find it with a search prompt of "Meson dependency isystem". That said, searching for "isystem" on the meson documentation does yield only 3 results. One of them is including the include_type field. I don't know if the explanation given there is sufficient to know what to do (if you don't know you're looking at the solution, that is). I found a link to a github issue that settles the matter rather quickly further down the list, but I don't consider having to resort to issues or bug-reports to find a solution a good solution.
AussieWog93 4y ago
If I had the option between going back in time and killing Hitler, or going back in time and preventing CMake from ever being written, I'd pick the latter every single time[1]. Same with Bluetooth, Qt and every other piece of janky garbage that works just well enough to survive, but badly enough that every single person on the planet hates it. [1] This is obviously hyperbole, before anyone gets "HN literal" in the replies.
- kaba0 4y ago
  What’s bad about Qt (besides not being able to write programs for it in anything besides C++ and to a degree python)
  - AussieWog93 4y ago
    Qt specifically is bad because it's full of quirks and footguns. The licencing and distribution is also a bit of a pain. On paper, it's great because it does everything and is cross-platform. In practice, though, including it with your product will introduce dozens upon dozens of completely preventable bugs and all kinds of bizarreness that will suck you away from solving the actual problems necessary to releasing your app.
    - vasvir 4y ago
      Having a major project in Qt 15 years ago under my belt I can't disagree more. The project started with Qt 2 and at some point migrated to to Qt 3 in half a day. KDE is written in Qt and frankly if it was not a good option that experiment wouldn't have succeeded so far given that the amount of commercial support is a fraction the one GNOME receives. (Yea I know - citation required). The quirks in Qt are coming form the fact that was trying and still tries to implement a sane C++ dialect and build system (qmake) in a time where the standardization efforts of C++ and event STL was not at the same level of today. For example So now we Boost for signal and slots. Do we still need moc? The same for collections, maps etc. When they go introduced there was no standard / portable solution. You can probably describe Qt like the C++ equivalent of the java promise (write once - compile everywhere) with its own support for sockets, filesystem and what else abstraction you can imagine off. Qt was an impressive feat for its time and a joy to program for. Much better than what the web was at the time with is amalgam of languages and text only interfaces. It took web and flexbox up to 2015 to be able to implement the holy grail layout https://en.wikipedia.org/wiki/Holy_grail_(web_design) https://en.wikipedia.org/wiki/Holy_grail_(web_design) .
vbezhenar 4y ago
I'm using shell scripts for my small C projects. Works awesome. I dread the time when I'd need to deal with those overcomplicated build systems.
- tristan957 4y ago
  Here is all that you need for a small C project, say an executable. project('hello', 'c') executable('hello', 'hello.c') Obviously use what you are comfortable with, but I don't see how this is overly complicated.
  - Koshkin 4y ago
    I guess, the point was, you do not actually need this for a small project, and for a larger project it would look dreadfully complex.
    - tristan957 4y ago
      If you are the only contributor, target one compiler, and one platform, then sure. > for a larger project it would look dreadfully complex How so? How do you avoid complexity?
  - vbezhenar 4y ago
    Now add something like clang with custom wasm flags there. Or Tigress for obfuscation. Launch node.js app for testing after build. Few obvious lines in shell script. I guess few weeks of learning the tools with other approaches. My unprofessional approach to C so far was to avoid libraries, even most standard library and write very simple C code (avoid C++ as well). Simple C code compiles at tremendous speed. Something like 100k lines per second or even faster. Especially if you don't need optimization (for development cycles). So you don't need to think about incremental compilation and things like that and it makes everything dumb simple.
jiggawatts 4y ago
Something that I learned from listening to Jonathan Blow about his new language Jai is that the implicit assumptions on which traditional C/C++ toolchains are built are horrendously out-of-date. The whole concept of "discovering" which compiler you have, what your linker is, and then using a DSL to generate a script that triggers shell commands is more than a little bonkers if you stand back and look at it objectively. It's common to see SDKs or APIs with 2-10 functions in them that weigh in at over 100 KB due to the overheads of having to deal with toolchains, platforms, and other sideshows that have no real contribution to the business at hand. Jonathan has demonstrated recompiling, linking, and reloading an entire game engine live, which then lets you escape the tarpit of having to add non-compiled DSLs to everything as a workaround for slow compile times. If your compile times are measured in hundreds of milliseconds, scripting isn't needed any more! No more bytecodes, or JIT, or any of that. Just churn the code through a single process that outputs an executable directly and you can sidestep the need for entire industries. This is why tools like CMake or Meson feel to me like they're solving the wrong problem. It's like selling a better horse when automobiles have been demonstrated by Henry Ford.
- schaefer 4y ago
  Okay, but I’m not in the Jai beta, and I have to use the tools available to me…
  - zbentley 4y ago
    Nim, D, Go, Rust, and several other languages in this space all offer a similarly integrated toolchain without the drawbacks of legacy build systems. And those are all free and available, unlike Jai.
    - georgyo 4y ago
      This is mostly true, but it is also because there is only one implementation of an these languages. Go for example has a gcc compiler as well. And that compiler has very different options than the one written in go.
bandrami 4y ago
Any time I've needed something other than make it's been a sign I need to refactor
- klodolph 4y ago
  You never really need something other than make, but I’d consider it borderline professional malpractice to try and wrangle medium-to-large size projects with make.
  - bandrami 4y ago
    IDK all of the BSDs seem to be OK
prabhu-yu 4y ago
How about Scons? I feel, Scons is much simpler even if it less efficient in speed of compilation. Please comment.
Cloudef 4y ago
Every time I have to deal with meson based projects, it needs incredible amount of hacks to build a project if you want to build it in slightly customized way or for bit more different platform. Meson is too smart and often tells you "no you can't do that", which can't be overridden without patching the meson's python code itself. I also find it bit sad, we need python to build something in the first place.
Klasiaster 4y ago
It's really a blessing that this project exists and was so well received and replaced Autotools in many areas already. That said, it has some learning curve for special cases (NB: the fact that it depends on Python may also need some workarounds in bootstrapping environments by e.g. compiling it first to native code or whatever but normally it's not a big deal as Python is around almost everywhere).
- Klasiaster 4y ago
  Ok, I wasn't aware of an alternative reimplementation in C: https://git.sr.ht/~lattis/muon/tree/master https://git.sr.ht/~lattis/muon/tree/master - bootstrapping without Python shouldn't be a problem then.

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 4y ago
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.
- aurelian15 4y ago
  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/ https://sr.ht/~lattis/muon/
  - mdaniel 4y ago
    I was going to try replacing the KeePassXC build (which is one of the more complicated CMake builds I've had hand-to-hand with) to see what that experience would be like, but they report all the Qt flavors are unsupported: https://muon.build/releases/edge/docs/status.html https://muon.build/releases/edge/docs/status.html I'm aware I could just vanilla Meson but I was specifically interested in kicking the tires on the dbg in Muon since CLion just recently added debugging to CMake and I wanted to compare and contrast
- endgame 4y ago
  Bootstrapping is something I care about a lot, too, and keeps me on GNU Autotools. Have you found any other options?
  - winter_squirrel 4y ago
    [dead]
  - tristan957 4y ago
    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/ https://sr.ht/~lattis/muon/
    - mdaniel 4y ago
      > 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
      - tristan957 4y ago
        It even has a debugger and an auto formatter. Meson is getting an auto formatter in https://github.com/mesonbuild/meson/pull/10971 https://github.com/mesonbuild/meson/pull/10971.
      - chombier 4y ago
        > type inference This means muon can fairly easily implement user-defined functions without making the language Turing complete. If they did this I would happily (re)consider switching from CMake.
- tristan957 4y ago
  You should read the blog post you are commenting on.
  - hawski 4y ago
    What do you mean? It is not a blog post, those are release notes, that do not seem to me to be relevant to my comment.
ironman1478 4y ago
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).
germandiago 4y ago
In Medium I posted some years back this, it is four articles: https://www.google.com/url?q=https://germandiagogomez.medium.com/getting-started-with-meson-build-system-and-c-83270f444bee&sa=U&ved=2ahUKEwi_5vaV7JH8AhWIF4gKHaKxBtEQFnoECAYQAg&usg=AOvVaw2jKPxwkTlvc-jrUFJ6bX5W https://www.google.com/url?q=https://germandiagogomez.medium...
- malkia 4y ago
  Thank you!
germandiago 4y ago
htttps://germandiagogomez.medium.com/getting-started-with-meson-build-system-and-c-83270f444bee&sa=U&ved=2ahUKEwi_5vaV7JH8AhWIF4gKHaKxBtEQFnoECAYQAg&usg=AOvVaw2jKPxwkTlvc-jrUFJ6bX5W
- malkia 4y ago
  Thanks! I'll check it out!
  - malkia 4y ago
    Seems like this was the right link - https://germandiagogomez.medium.com/getting-started-with-meson-build-system-and-c-83270f444bee https://germandiagogomez.medium.com/getting-started-with-mes...

lazypenguin 4y ago

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 4y ago
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 4y ago
  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 4y ago
    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
    - MBCook 4y ago
      Not the GP but I read their point not as pro-Meson but more that both Meson and CMake feel like overkill for a single platform/architecture project.
      - tristan957 4y ago
        If you are the only contributor, targeting one compiler, on one platform, then yep, I could see how this might be overkill.

hulitu 4y ago

I hate the world today. Every program needs its own build system. /s

einpoklum 4y ago

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).

wirrbel 4y ago
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 4y ago
  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.
- einpoklum 4y ago
  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?
  - wirrbel 4y ago
    1. dunno never used CUDA. Pretty sure you can hack something together but I am the first to admit that it will be a bumpy ride if you start from 0 2. depends on what you are building. My users run WSL so essentially Linux user space. 3. are you asking for interdependencies? It works in principle I would say, for an elaborate foolproof setup I would anyway use bazel or buck in such a situation.

FpUser 4y ago

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 4y ago
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 4y ago
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.

hackerbrother 4y ago

Why do many C/C++ projects have both Meson and Ninja commands in their install instructions? Shouldn't only one be necessary?

Un1corn 4y ago
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 4y ago
  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 4y ago
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.
germandiago 4y ago
meson compile will invoke the backend used.

oldgradstudent 4y ago

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 4y ago
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 4y ago
  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 4y ago
    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.

majoe 4y ago

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.

synergy20 4y ago

Played with Meson for one hour and bailed out, will stay with makefile/cmake. I especially like cmake that can convert pkg-config from -I header.h to -isystem header.h.

bonzini 4y ago
Like "dependency(..., include_type: 'system')"?
- synergy20 4y ago
  thanks, 1 hour was obviously enough to figure this out. time is just tight and it's hard for new things like meson or the rest of 20 different build systems to stand out, unless they're really simple/quick to take on I guess.
  - bonzini 4y ago
    To be honest I just googled "Meson dependency isystem" and any of the first few results would have given the answer (I used the third which was a bug report). That said, using isystem for dependencies is a relatively advanced concept, not something I would do in the first hour of trying Meson.
    - ablob 4y ago
      I did not find it with a search prompt of "Meson dependency isystem". That said, searching for "isystem" on the meson documentation does yield only 3 results. One of them is including the include_type field. I don't know if the explanation given there is sufficient to know what to do (if you don't know you're looking at the solution, that is). I found a link to a github issue that settles the matter rather quickly further down the list, but I don't consider having to resort to issues or bug-reports to find a solution a good solution.

AussieWog93 4y ago

If I had the option between going back in time and killing Hitler, or going back in time and preventing CMake from ever being written, I'd pick the latter every single time[1]. Same with Bluetooth, Qt and every other piece of janky garbage that works just well enough to survive, but badly enough that every single person on the planet hates it. [1] This is obviously hyperbole, before anyone gets "HN literal" in the replies.

kaba0 4y ago
What’s bad about Qt (besides not being able to write programs for it in anything besides C++ and to a degree python)
- AussieWog93 4y ago
  Qt specifically is bad because it's full of quirks and footguns. The licencing and distribution is also a bit of a pain. On paper, it's great because it does everything and is cross-platform. In practice, though, including it with your product will introduce dozens upon dozens of completely preventable bugs and all kinds of bizarreness that will suck you away from solving the actual problems necessary to releasing your app.
  - vasvir 4y ago
    Having a major project in Qt 15 years ago under my belt I can't disagree more. The project started with Qt 2 and at some point migrated to to Qt 3 in half a day. KDE is written in Qt and frankly if it was not a good option that experiment wouldn't have succeeded so far given that the amount of commercial support is a fraction the one GNOME receives. (Yea I know - citation required). The quirks in Qt are coming form the fact that was trying and still tries to implement a sane C++ dialect and build system (qmake) in a time where the standardization efforts of C++ and event STL was not at the same level of today. For example So now we Boost for signal and slots. Do we still need moc? The same for collections, maps etc. When they go introduced there was no standard / portable solution. You can probably describe Qt like the C++ equivalent of the java promise (write once - compile everywhere) with its own support for sockets, filesystem and what else abstraction you can imagine off. Qt was an impressive feat for its time and a joy to program for. Much better than what the web was at the time with is amalgam of languages and text only interfaces. It took web and flexbox up to 2015 to be able to implement the holy grail layout https://en.wikipedia.org/wiki/Holy_grail_(web_design) https://en.wikipedia.org/wiki/Holy_grail_(web_design) .

vbezhenar 4y ago

I'm using shell scripts for my small C projects. Works awesome. I dread the time when I'd need to deal with those overcomplicated build systems.

tristan957 4y ago
Here is all that you need for a small C project, say an executable. project('hello', 'c') executable('hello', 'hello.c') Obviously use what you are comfortable with, but I don't see how this is overly complicated.
- Koshkin 4y ago
  I guess, the point was, you do not actually need this for a small project, and for a larger project it would look dreadfully complex.
  - tristan957 4y ago
    If you are the only contributor, target one compiler, and one platform, then sure. > for a larger project it would look dreadfully complex How so? How do you avoid complexity?
- vbezhenar 4y ago
  Now add something like clang with custom wasm flags there. Or Tigress for obfuscation. Launch node.js app for testing after build. Few obvious lines in shell script. I guess few weeks of learning the tools with other approaches. My unprofessional approach to C so far was to avoid libraries, even most standard library and write very simple C code (avoid C++ as well). Simple C code compiles at tremendous speed. Something like 100k lines per second or even faster. Especially if you don't need optimization (for development cycles). So you don't need to think about incremental compilation and things like that and it makes everything dumb simple.

jiggawatts 4y ago

Something that I learned from listening to Jonathan Blow about his new language Jai is that the implicit assumptions on which traditional C/C++ toolchains are built are horrendously out-of-date. The whole concept of "discovering" which compiler you have, what your linker is, and then using a DSL to generate a script that triggers shell commands is more than a little bonkers if you stand back and look at it objectively. It's common to see SDKs or APIs with 2-10 functions in them that weigh in at over 100 KB due to the overheads of having to deal with toolchains, platforms, and other sideshows that have no real contribution to the business at hand. Jonathan has demonstrated recompiling, linking, and reloading an entire game engine live, which then lets you escape the tarpit of having to add non-compiled DSLs to everything as a workaround for slow compile times. If your compile times are measured in hundreds of milliseconds, scripting isn't needed any more! No more bytecodes, or JIT, or any of that. Just churn the code through a single process that outputs an executable directly and you can sidestep the need for entire industries. This is why tools like CMake or Meson feel to me like they're solving the wrong problem. It's like selling a better horse when automobiles have been demonstrated by Henry Ford.

schaefer 4y ago
Okay, but I’m not in the Jai beta, and I have to use the tools available to me…
- zbentley 4y ago
  Nim, D, Go, Rust, and several other languages in this space all offer a similarly integrated toolchain without the drawbacks of legacy build systems. And those are all free and available, unlike Jai.
  - georgyo 4y ago
    This is mostly true, but it is also because there is only one implementation of an these languages. Go for example has a gcc compiler as well. And that compiler has very different options than the one written in go.

bandrami 4y ago

Any time I've needed something other than make it's been a sign I need to refactor

klodolph 4y ago
You never really need something other than make, but I’d consider it borderline professional malpractice to try and wrangle medium-to-large size projects with make.
- bandrami 4y ago
  IDK all of the BSDs seem to be OK

prabhu-yu 4y ago

How about Scons? I feel, Scons is much simpler even if it less efficient in speed of compilation. Please comment.

Cloudef 4y ago

Every time I have to deal with meson based projects, it needs incredible amount of hacks to build a project if you want to build it in slightly customized way or for bit more different platform. Meson is too smart and often tells you "no you can't do that", which can't be overridden without patching the meson's python code itself. I also find it bit sad, we need python to build something in the first place.

Klasiaster 4y ago

It's really a blessing that this project exists and was so well received and replaced Autotools in many areas already. That said, it has some learning curve for special cases (NB: the fact that it depends on Python may also need some workarounds in bootstrapping environments by e.g. compiling it first to native code or whatever but normally it's not a big deal as Python is around almost everywhere).

Klasiaster 4y ago
Ok, I wasn't aware of an alternative reimplementation in C: https://git.sr.ht/~lattis/muon/tree/master https://git.sr.ht/~lattis/muon/tree/master - bootstrapping without Python shouldn't be a problem then.