Meson[0] has been gaining in popularity and has migration tools for cmake projects.
Large projects such as systemd and gnome[1] have migrated or have been migrating for years
[1] https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
Large projects such as systemd and gnome[1] have migrated or have been migrating for years
[1] https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
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.
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).
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.
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.
Yaw super lightweight ...
I haven't used virtualenv very much, but I've been doing similar things for longer than virtualenv has been around. You need a `python` binary on PATH and a PYTHONPATH pointing to where you want to get your libraries from. virtualenv packages this up into a directory in a more user friendly fashion.
Most docs I've seen on Python2/3 advise on choosing one or the other, ideally 3. Which implies mixing should either be done very carefully or with a plan to transition to 3.
I get that some accidents of history have caused headaches. The deep adoption by distros have caused problems when people just want to use Python/libs installed with the OS (as well as moving to Python 3), authoring packages hasn't been great historically, etc.
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 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.
But to be fair, I usually just clone a Virtualbox machine because I'm used to the workflow. :)
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!
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.
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
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.
Having everything in a single standalone executable is vastly preferable IMHO.
Meson has no glob support.
Meson does not support any form of remote caching.
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 how dependencies are discovered in cmake. Dependencies are added with calls to find_package, and if you have to include dependencies that don't install their cmake or even pkconfig module then you add your own Find<dependency>.cmake file to the project to search for it, set targets, and perform sanity checks.
* 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.
You forgot to mention that the language is awful (but that usually doesn't get in the way IME).
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...
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.
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.
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.
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.
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.
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.
You are very fortunate if you import libraries that just work. This is also true for "modern" CMake.
I'm probably biased as I write and maintain Starlark for C++ codebases on a daily basis.