Announcement

Collapse
No announcement yet.

Meson v0.60 Build System Brings Numerous Improvements

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Meson v0.60 Build System Brings Numerous Improvements

    Phoronix: Meson v0.60 Build System Brings Numerous Improvements

    Meson 0.60 was released on Sunday as the newest version of this increasingly popular and widely-used cross-platform build system...

    https://www.phoronix.com/scan.php?pa...0-Build-System

  • #2
    Does it support the equivalent of "make uninstall" yet? autotools has it and it's very useful to not clean up things manually.

    Comment


    • #3
      Originally posted by zboszor View Post
      Does it support the equivalent of "make uninstall" yet? autotools has it and it's very useful to not clean up things manually.
      Just double-checked to be sure and meson 0.59.2 generates "uninstall" target, and it works exactly as expected. Quick Google search indicates the feature is supported since Meson 0.38.0.

      Comment


      • #4
        I have spent a, well, non-trivial amount of time over the past few decades banging on autotools build systems. Sure, it's powerful, supports every weird obsolete niche architecture you can think of, but man is it baroque.

        Recently I converted one of my hobby projects over to meson + ninja, and it's such a breath of fresh air. Size of the build scripts shrunk to a small fraction of their previous size, and they are easy to grasp and reason about. And ninja is really blazing fast.

        Comment


        • #5
          Originally posted by jabl View Post
          I have spent a, well, non-trivial amount of time over the past few decades banging on autotools build systems. Sure, it's powerful, supports every weird obsolete niche architecture you can think of, but man is it baroque.

          Recently I converted one of my hobby projects over to meson + ninja, and it's such a breath of fresh air. Size of the build scripts shrunk to a small fraction of their previous size, and they are easy to grasp and reason about. And ninja is really blazing fast.
          But how are you going to build on A/UX? /s

          More seriously, that is neat. My personal projects use cmake + ninja already, so I'm not sure how much I would gain from switching to meson. Do you have any experience with that?

          Comment


          • #6
            Originally posted by Vorpal View Post
            More seriously, that is neat. My personal projects use cmake + ninja already, so I'm not sure how much I would gain from switching to meson. Do you have any experience with that?
            I have a bit of experience in writing meson buildsystems for projects using cmake (I wrote two meson wrappers for cmake-based projects). In my experience meson-based buildystem is ~30% smaller than cmake one, much more readable and understandable, definitely easier to write, and meson has some built-in features that make it easier to handle certain edge-cases.

            Meson supports cmake syntax for template files, so you don't need to rewrite them when porting buildsystem (which is neat). It also gives some features "for free" (such as easy generation of coverage reports, compile_commands.json generated OOTB, or sane approach to handling warning flags). I think cmake might still work better if you want Visual Studio integration though (but Linux users probably don't care that much).

            One tiny problematic thing is: Ubuntu LTS is extremely slow in adopting newer Meson versions (even Debian Stable is faster) - that's problem caused by Canonical though . If that'll be a problem (you want to use a feature that's available in newer Meson than Ubuntu provides) you can install Meson via pip.

            Comment


            • #7
              Yeah, we have changed a pile of nasty shell into a pile of messy python... The problem with build systems is that they begin as simple projects with clear objectives, only to quickly absorb tons of edge cases and tight couplings with compilers making their abstractions leak in a terrible manner.

              For instance, as far as I understand in this project meson was for the "mess" and ninja was supposed to be an agnostic job manager, but it turns out it parses the dependencies files, so it now has a list of supported compilers.

              Comment


              • #8
                Originally posted by Vorpal View Post
                My personal projects use cmake + ninja already, so I'm not sure how much I would gain from switching to meson. Do you have any experience with that?
                I have a bit of experience with cmake, but not particularly recent. IMHO while it's not as nice as meson, it's pretty decent, and has more features. Modern cmake (3.x+) has features to avoid some error-prone idioms on 'old' cmake. It also seems that meson is used more by Linux developers (e.g. systemd, gnome, freedesktop etc. stuff is mostly meson these days, and meson has nice integration with libraries that provide pkg-config files), whereas cmake has perhaps more universal appeal.

                I'd say unless you feel cmake is some particular pain point for you it's not worth switching. And if you have some particular pain point, see if modern cmake provides some idiom that solves it before starting over from scratch with another build system.

                Comment


                • #9
                  Originally posted by Vorpal View Post

                  But how are you going to build on A/UX? /s

                  More seriously, that is neat. My personal projects use cmake + ninja already, so I'm not sure how much I would gain from switching to meson. Do you have any experience with that?
                  From my experience, it does not matter if your project is simple. As soon as you add complex dependencies you will be hurt by the lack of mesons extensibility.
                  You will end up with extra python/shell/whatever scripts and tools wheres you could use the builtin scripting, tools and installed cmake configs on the other size.

                  Think of for ex QT or protobuf which install cmake macros so your project can use functionality like codegens. You will always use the correct tools/scripts depending on what you have installed or staged (cross-builds).
                  I stopped my attempts at meson when I had no way to use libraries with helper scripts defining some complicated linker/assembler setup for embedded platforms.
                  (if written in CMake scripts, cmake is the only thing you need - hypothetically if anyone ports meson to another language there will be still mostly python scripts that where used as extension around)

                  Second issue is tool support, CMake is well supported with Eclipse and Clion, and also non-full-unix is better supported. Might be just a matter of time, but right now theres clear advantages.

                  Comment


                  • #10
                    Thanks. Doesn't sound like it is worth switching for an exiating project where cmake works well. Also lack of good integration with code gen tools would be a bit of a pain for me. And while I don't care about Windows, I do care about other *nix than just Linux.

                    Might be something to experiment with if I ever do another c/c++ project in the future though. These days most new things I write are in python, so setuptools is what I default to.‚Äč

                    Comment

                    Working...
                    X