Announcement

Collapse
No announcement yet.

Meson Build System Takes 45% Less Time Than Autotools For Epoxy

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

  • #11
    I personally have not encountered a build system that has surpassed Waf as an Autotools replacement, so it'll be interesting to see Meson attempt to do that.

    For anybody using SCons, or thinking about it... DON'T USE SCONS! The approach/design used by it prevents simple things from working, like checking for a library/header in the configuration stage then prevents your code from actually being rebuilt when that library/header changes, essentially hindering SCons useless as a build system if you ever want to configure for the system (which is probably always). Waf was basically designed and built as a result of somebody discovering all of the problems with SCons.

    Comment


    • #12
      Originally posted by Delgarde View Post

      ... I'm a little wary of a build tool that's basically embedding a full-fledged scripting language.
      You can either design in a full language now, or try to patch it on later. Which is wiser?

      Build scripts always have the tendency to get horrifically complicated very very quickly
      If you think any project has an over-complicated build script, by all means submit a patch to simplify it.

      Remember, the point of a build script is to automate complex tasks, so the human developers don’t have to perform them.

      Comment


      • #13
        But is it faster than CMake+Ninja?

        Comment


        • #14
          Originally posted by alvez View Post
          But is it faster than CMake+Ninja?
          I took over the Epoxy maintainership after a CMake build system was added to it, so I can at least attempt an authoritative answer.

          Given the size of the project, both CMake/Ninja and Meson/Ninja are pretty close in terms of speed — though, to be fair, the CMake build was pretty messy. CMake also uses Ninja a bit wrong, the same way it uses Make a bit wrong, so it's not as fast as it could be; see: https://lwn.net/Articles/706653/

          The reason why I went with Meson instead of cleaning up the CMake mess was that messy CMake builds and clean CMake builds are virtually indistinguishable. Dependency discovery is a tragedy of copy-pasted files that never get updated and whose ownership is spotty at best. The language has Turing-completeness built on top, which means that the syntax is a tragic carousel of mistakes and that inspecting the build from the outside requires running the build. CMake is the SVN of build systems: it's autotools, except *better*. The problem is: if all you wanted was a better CVS then you're probably missing out on something that is drastically better because it has a different design.

          Meson is simpler, easier to follow, has learned from all the errors that both autotools and CMake made. It make may new, and exciting mistakes along the way, but at least the basic features for a build system — speed, dependency resolution, reproducibility, cross-compilation, introspection, ease of maintainability — are covered.

          Comment


          • #15
            Hm, looks interesting. I might migrate my own projects as well, not because of performance (tbh I doubt it's much faster than CMake+Make is when the project is mostly just a few platform checks + a long list of .cpp files), but rather because CMake inevitably becomes a mess even when doing basic stuff like including subdirectories (PARENT_SCOPE and such) and I really don't like its syntax.

            Comment


            • #16
              Originally posted by ebassi View Post

              The reason why I went with Meson instead of cleaning up the CMake mess was that messy CMake builds and clean CMake builds are virtually indistinguishable.
              Some of us do try...

              Comment


              • #17
                So I've been looking into this meson thingy. For decade or so I'd written my own GNUMakefile trees, then over the past year have switched entirely to qmake. Meson might have some advantages; seems to. But it looks like I might inherit a largish project on CentOS 6, Python-2.6, and for some unfathomable reason meson appears to require upon python-3.x

                I haven't gotten into the new project yet, don't even know what the current devs are using. Might be something good and usable, for all I know. Just trying to keep an open mind and options.

                Comment


                • #18
                  Originally posted by pipe13 View Post
                  ... for some unfathomable reason meson appears to require upon python-3.x
                  Why would you want a modern project to be built on an obsolete version of Python?

                  Comment


                  • #19
                    Originally posted by ldo17 View Post

                    Why would you want a modern project to be built on an obsolete version of Python?
                    Unfathomably italicized; </irony> implied.

                    Comment


                    • #20
                      Originally posted by ebassi View Post

                      I took over the Epoxy maintainership after a CMake build system was added to it, so I can at least attempt an authoritative answer.

                      Given the size of the project, both CMake/Ninja and Meson/Ninja are pretty close in terms of speed — though, to be fair, the CMake build was pretty messy. CMake also uses Ninja a bit wrong, the same way it uses Make a bit wrong, so it's not as fast as it could be; see: https://lwn.net/Articles/706653/

                      The reason why I went with Meson instead of cleaning up the CMake mess was that messy CMake builds and clean CMake builds are virtually indistinguishable. Dependency discovery is a tragedy of copy-pasted files that never get updated and whose ownership is spotty at best. The language has Turing-completeness built on top, which means that the syntax is a tragic carousel of mistakes and that inspecting the build from the outside requires running the build. CMake is the SVN of build systems: it's autotools, except *better*. The problem is: if all you wanted was a better CVS then you're probably missing out on something that is drastically better because it has a different design.

                      Meson is simpler, easier to follow, has learned from all the errors that both autotools and CMake made. It make may new, and exciting mistakes along the way, but at least the basic features for a build system — speed, dependency resolution, reproducibility, cross-compilation, introspection, ease of maintainability — are covered.
                      Thanks for the answer. However I do like CMake and have yet to encounter many of the problems people complain about. Must be doing something right

                      Comment

                      Working...
                      X