But the meson installation has many dependencies, it is not very lightweight, it needs python, ninja, and xmake has built-in luajit, no third-party dependencies, more lightweight

Python is preinstalled on any major Linux distro. Ninja is tiny, so those don't seem that heavyweight.

Python also has version compatibility issues, such as: python2.x, 3.x. Also need the user to install the specified version of python

Any new project will very, very likely be using Python3. It appears like that applies to meson. `python3` is the expected binary (`python` is still expected to point to Python 2 for the foreseeable future and `python2` being the explicit binary--some distros have jumped the gun on `python`). Similarly, they have completely different accompanies executables (pip3, wheel3, pydoc3) and completely separate library paths. What sort of compatibility issues have you seen?

The requirements say Python 3.5 or newer. That was released in 2015. Outside of major versions, Python has generally been forwards compatible (especially if you're testing). After more than a decade of use, the only grumbles with supporting old Python version is not getting to use new features (or working around fixed bugs).

I say this as someone who still uses Python 2 every day.

The sooner debian kills the python = python2 association and python3 becomes the default provider of 'python' the better, I think I read that it's scheduled for this year finally.

I don't blame the OS guys. Python has been around for 30 years and many distros built a lot of their utilities around Python 2. Getting rid of Python 2 sounds like a Herculean effort that could only start after Python 3 settled down and required libraries were ported over (or replacement libraries written using more modern conventions).

I'm glad we seem to be past the big inflection point and hope to put Python 2 behind us. But I can see never changing `python` from Python 2 (just not have one when Python 2 isn't installed).

On the contrary, Arch Linux has ‘python’ as Python 3 and ‘python2’ as Python 2. Although most of the Linux users are on Ubuntu, you can’t ignore those other distributions.

Arch was what I had in mind as an OS that jumped the gun against the advice of the Python devs (at least that's a simplified history). I thought there was another distro, but I wasn't sure if they had rolled that back.

To the point of the comment thread, that would only be an issue if you're maintaining a Python 2 codebase and using modern Arch. If you're creating a Python 3 codebase you're likely calling `python3` and even calling `python` isn't a problem for you.

> Python also has version compatibility issues, such as: python2.x, 3.x.

If that really bothers you then just create a virtual environment and locally deploy whatever version you want to run. That issue ceased to be a concern years ago.

> just create a virtual environment

Yaw super lightweight ...

I think GP means `python3 -mvenv my_venv` rather than running in a VM or any heavyweight virtual environment. At least that's how I interpret 'virtual environment' in a pythonic context, and they're certainly lightweight enough.

What I took GGP to be talking about though was lightweight in terms of cognitive load. Like "can I just run the thing please!" aka yak shaving [0]

[0] https://seths.blog/2005/03/dont_shave_that/

That you needed four paragraphs to get your point across kind of emphasises my point.

I don't mean to be rude, but the key to getting people's attention is to get your point across quickly. As soon as somebody starts going all you have to do is install a frobozz and murtle a plinth I really just lose interest.

EDIT - doubting myself I went back up the thread here and this topic kicks off with "meson installation has many dependencies, it is not very lightweight" ("lightweight" operationally defined here for this discussion) - to which somebody replies "it doesn't matter, Ninja includes Python" or words to that effect. "it's not the correct version of Python" is the general gist of what comes next to which our GGP here says "all you have to do" is set up a python virtual environment, which is around the point where I start to feel frustrated and the need to go do something interesting.

So to be clear, the discussion is not about python being lightweight, but meson, and trying to wave complexity away with yet another layer of complexity (even if it's something as well known as python virtualenvs) is not reducing complexity but hiding it, IMO.

I honestly wasn't trying to be combative. I tried to make my comment just long enough to give context (showing my understanding of the solution and the assumptions I'm making). I'm not trying to interject my opinion, but see where my assumptions might be wrong.

I agree long wandering threads are difficult to follow.

I have little interest in new C++ build systems, but will jump in and contribute when I see a familiar problem I want to learn more about like managing sizable Python codebases. Python 2/3 isn't relevant at all to meson and I don't see the docs mentioning any need for version or package management. I've only ever heard/seen virtualenv needed in project management, never in distributed software. Is your beef with Python or any software using an interpreted language? Outside of the 2to3 transition and being deeply integrated in many distros, it has the fundamental problems other interpreted languages have and are handled in the same way.

It is if you run it inside a Docker container... no mess, no fuss...

I cant tell if you’re joking or not ;)

Depends if someone's already written the Dockerfile for you ;)

But to be fair, I usually just clone a Virtualbox machine because I'm used to the workflow. :)

I have python 2 vs 3 issues if not every day, then at least 3 times a week, because of being stuck with a version of third party software that uses Python 2 (ArcGIS 10 series) for part of my code base. Of course Python apologists are now going to say 'oh you're just one guy in a niche situation', and 'yeah that's what you get for not upgrading to the latest version of all software', or any of the dozens of other excuses and blame I get anytime I have to defend why I need to use Python 2. Fact is still that I'm bound by external constraints and that Python versioning is a real problem in my day to day work, and yes that is in 2019. Look, Python isn't much worse or better than most other languages in its niche, but please do away with the 'everything about Python is easy and great' spiel.

In fairness to the python community by-and-large, they are very supportive of legacy users and niche configurations. Python 2.x seems like something like 15 years now past its sell by date and is still actively supported. There's a lot of patience there ... people will make the leap when they're ready.

I think the pressure to always be on the latest and greatest is what did for the ruby and perl communities, and this is why python, and to a certain extent javascript are still going strong!

Not disagreeing with you, just clarifying: I'm not even complaining so much about the Python 'development' community (i.e., those writing the interpreter and most of the people writing libraries); what irks me is the 'evangelists', Python users who feel the need to proselytize about things that are obviously not perfect, but claim they are and straight up dismiss any objections or real world concerns. I'm talking about the people who with a straight face call themselves 'Pythonistas'. Jebus, if so much of your self image and self worth is tied up in the programming language you like to use most, you need professional help. Of course all languages have people like this, and most 'communities' that are not software related have similar people too, it's just that posts like this seem to bring out this sort of hanger-ons. It probably also has something to do with me turning into Statler or Waldorf over time. Meh.

There are a few different meanings of the word lightweight, and I get a sense you're not using the one that I or GP are using.

I am also annoyed by Python 2 vs Python 3 situation, however not because of the current incompatibility but about the potential Python 3 vs Python 4 incompatibility that the Python developers have shown to not care about introducing in the future.

If they promise to never break backward compatibility again in the future i might change my stance though, i mostly try to avoid Python than anything than a simple calculator or quick and dirty scripts because i do not want to write any code that may break in 2-3 years without me doing anything wrong.

The switchover to Python3 has taken 10 years (as originally predicted).

Guido said there would never be a Python 4, though he has handed over the reigns so who knows.

As a Python dev, I wouldn't mind a Python 4 if it fixed some of the older / crustier corners of the API.

    export PIP_REQUIRE_VIRTUALENV=true

It's the only sane way to use Python.

Pretty much everything has moved to Python 3 now.

Python isn't installed on Windows, the pre-installed python version on macOS is stuck at 2.7.10.

ninja isn't installed on macOS and Windows, and both systems require to first install a package manager before installing ninja, or compile ninja from scratch.

ninja on windows just requires you to download ninja.exe and put it in your path

python and ninja are also bundled in the installer for meson.

AFAIK Meson requires a python installation, which is a non-trivial dependency and on some platforms requires additional manual setup steps.

Having everything in a single standalone executable is vastly preferable IMHO.

Depending on Python is actually much better than dependencies on other runtimes, just as Java. Firstly, Python is everywhere now. And secondly, you can just 'pip install --user' and use it even without root privileges (which is a great thing if you're in a restricted corporate environment).

The Cmake migration tools are not very good.

Meson has no glob support.

Meson does not support any form of remote caching.

Meson doesn't seem to be a significant improvement over CMake beyond syntactic sugar. It uses the exact same, unreliable models as CMake, just with a slightly nicer-seeming syntax and about 242 more dependencies.

I really like Meson, but I've found with it that the corner cases where the simple syntax doesn't work get really hairy really fast, eg producing vst plugins, or linking against something that doesn't have a deep integration with pkgtool or such.

Meson looks nice, but it still lacks a way to tell it where your dependencies are installed(like cmake’s CMAKE_PREFIX_PATH). You can try to get by, by setting pkg config path, but it doesn’t help for dependencies that don’t support pkgconfig.

You can try xmake's dependency package management.

    add_requires("libuv master", "ffmpeg", "zlib 1.20.*")
    add_requires("tbox >1.6.1", {optional = true, debug = true})
    target("test")
        set_kind("shared")
        add_files("src/*.c")
        add_packages("libuv", "ffmpeg", "tbox", "zlib")

That's not entirely true, CMAKE_PREFIX_PATH is used in find_package and find_library calls.

Why migrate from CMake to meson?

CMake feels a lot like C++89: Lots of things you can do, but there are problems:

* No standardization or opinionated design, so you can't share your work easily.

* No sane defaults, so your build system is always fragile, difficult to maintain, and done wrong.

* No best practices, so people keep making the same mistakes over and over.

* Misguided attempt to remain compatible with the steaming pile of legacy they've accumulated over the years.

* Bad documentation, so there's no way to learn how to do things better.

* Steep learning curve with limited payoff, so most people don't bother.

Meson does some of these things better. It's still not pretty, but it's nicer to use than CMake.

1 and 3 are not true anymore, the new canonical CMake way is targets with attached dependencies, header file search paths, compiler flags and possibly other things. Bad documentation - well yeah, it's specifically missing first-party best practices and howto documentation and the third-party documentation as well as really old first-party documentation in the CMake wiki often recommends bad old practices.

You forgot to mention that the language is awful (but that usually doesn't get in the way IME).

Xmake will be better, you can try it.

Nobody who has used CMake would ask that so I assume you haven't!

The answer is that CMake is mad and full of gotchas. Think of it like the PHP of build systems. Here is a classic example:

https://cmake.org/cmake/help/latest/command/if.html#variable...

This is a reasonable programming language design choice.

CMake actual gotchas I dislike enough to avoid it as much as possible include defaulting to cached information, even after I make changes, and preferring "smart", opaque and even hard to track down scripts to explicit user input. It seems optimized for cleverness and conciseness, at the expense of reliability and required user effort.

This is actually a useful comment and points out something I didn't know (about how the CMake if statement resolves variables).

In my experience the primary reason people migrate is that it is significantly simpler for ordinary developers to maintain and configure builds in Meson. They both target ninja but the learning curve for CMake is definitely steeper.

Cmake has tooling and is supported by IDEs. Does Meson have anything comparable?

A better question is does it need to have tooling or IDE support to be worked with?

It's good to have tooling and IDEs for CMake because CMake is complicated and hand-editing the files is very tedious. But if Meson eliminates the tedium of CMake by providing you with different abstractions then you don't actually need the IDEs or tooling.

CMake can generate IDE workspace files, which makes it possible to use Visual Studio almost natively - the almost being, the ide is "read only" with respect to project settings and files - but on a stable project, that feels very close to native.

I have not used Meson, but other build environments (e.g. Make) don't interact as well with IDEs as CMake does (with the exception of premake, which is mostly dead.

This is not what IDE support means for the most part. The big question is does the IDE understand how the files are compiled well enough for its autocompletion and jump-to-definition features to work. A build system/IDE combo which does not support this is DOA to most users. Sadly, there is no standardisation of the interface between IDEs, build systems, and compilers (though the language server spec from Microsoft is making some headway in this regard), so each of these integrations needs to be rebuilt each time, making development of new build systems extra painful.

> A better question is does it need to have tooling or IDE support to be worked with?

No, that's the wrong question and one that's only purpose is to deflect attention from its shortcomings.

All build tools need tooling because if they are adequately integrated into development workflows they are transparent and easy to use. Cmake meets that requirement, and until other alternative build systems do then they will always be far more complicated.

In my mind CMake and Meson are tools for engineers to use in solving problems. If one tool needs some support tooling in order to be usable, then I'm intrinsically less interested in using it simply because there's some extra stuff I have to bolt on before it becomes useful. So I don't see why you think it's "the wrong question" here.

Another poster has explained the IDE support is about IDEs being able to parse CMake files, and I can say that back in the day before CMake IDEs would parse the C/C++ directly using a compiler to output an abstract syntax tree that they would use. So for example Eclipse has this notion of "Build configurations" which allows you to control how this parsing occurs and which files the parser considers valid and what symbols are predefined. Which is IDE support very much like you're looking for from CMake. I worked with it for several years at my last job to provide support for other engineers working with a Make-based build system.

cmake has the best integration of any third party build tool, but if you can lock yourself to one IDE the ability to click "new file" and have the file created, added to version control, and the build system all in one easy step is powerful.

> A better question is does it need to have tooling or IDE support to be worked with?

C++ really benefits from it. ctrl+click on a symbol is much more sane than (re)teaching Argument Dependent Lookup rules to all of the engineers in your organization.

CMake is only complicated if you need to make use of its complicated features, which many build systems simply omit. Meson looks nice though.

Oh, the number of hours of my life I spent debugging CMake files of third party libraries.

You are very fortunate if you import libraries that just work. This is also true for "modern" CMake.

Bad code is an unfortunate fact of life. How does that go away. This could be either easier debugging, some enforcement of clean code (how is that possible), the tool is limited so you can't do complex things, or just so far only good coders have been involved not the masses of bad coders. My default assumption is the last, but I'm willing to be proven wrong.

Good defaults can take you very far.

what about Bazel ? https://bazel.build/

Bazel has been significantly faster than cmake/make on the codebases I've tried it on. It has a bunch of warts, but it has been a better framework to build on than anything else I've encountered.

I'm probably biased as I write and maintain Starlark for C++ codebases on a daily basis.

In my benchmarks Bazel was the fastest of the lot, including Meson with Ninja.

Did you publish your benchmarks anywhere?