1. 30
  1.  

  2. 3

    While I appreciate the removal of autotools, is making me have a Python interpreter any better? I guess it’s the case that many of us already do, so then I’ll ask does it work on 2.x and 3.x? And, I’m a bit out of the loop, has RedHat enterprise started shipping 3.x as the system version?

    1. 15

      While I appreciate the removal of autotools, is making me have a Python interpreter any better?

      I assume that the developers feel that making you install Python, which is dirt simple in most environments, is a lot easier than them having to continue to live through the endless hell that is autotools, forever.

      1. 6

        Well, the question, which @glesica answers here, is which version? And my ask about RedHat is because for a while RedHat wouldn’t ship anything more than Python 2.4, which was ancient. If Meson doesn’t take into consideration the versions of Python that are default on a bunch of different OSes, then it could be a burden on people.

        What autotools has going for it is acceptance, and therefore, the requirements for it are readily available, easily, on most systems. That doesn’t mean we shouldn’t strive for something better (please, please, please, do!) but we still should be mindful of the dependencies we’re adding when we adopt a new tool.

        1. 7

          Redhat should bear some of the burden for stranding people on a desert island as well.

          1. 2

            No doubt! But that still doesn’t make it easy for some people to meet the dependency easily.

          2. 4

            That’s no longer true. And you can easily get python3 from redhat software collections.

            1. 2

              Excellent! I can adjust my preconceived notions that RedHat is too far behind the times to be useful.

        2. 10

          The change means that GTK+ master now has a build-time dependency on:

          • Python 3.x
          1. 4

            I know nothing about meson, but it would not surprise me that the developers who maintain the build scripts find it easier to work with than autoconf.

            1. 2

              I don’t know much about Meson either, as I don’t really have use for it.

              Having said that, I’ve worked with Jussi the Meson guy, for a long time not too long ago, and he would not have it any other way :)

              Way cool he made it through with GTK, it didn’t come easy.

              Maybe this will inspire more people to look at it as an alternative.

            2. 1

              I think RedHat is trying to stop shipping python2 entirely. https://lwn.net/Articles/729366/

            3. 2

              Meson looks interesting. I usually use CMake when a C/C++ project gets too complex for good old make, but Meson’s documentation looks way better than CMake’s.

              1. 1

                This seems cool, but I don’t see an easy way to select 32-bit / 64-bit build on the same 64-bit machine, and support for compilers seems to be slightly-above-basic – I mean, there is some Rust, D or Swift support, but i.e. I don’t see support for MS assembler files (*.asm).

                Also it has some bugs, like if you use msys2 environment and Visual Studio dev tools, Meson can call /usr/bin/link.exe instead of VS’ link.exe, depends on the sequence of directories in your $PATH (Meson seems to just use “link.exe” instead of link from compiler’s directory).

                However, I’ll pick the DSL of Meson over CMake’s DSL any day.