19 ms·

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 migr

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 [0] https://mesonbuild.com/ https://mesonbuild.com/ [1] https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

waruqi 8y ago
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
- shaklee3 8y ago
  Python is preinstalled on any major Linux distro. Ninja is tiny, so those don't seem that heavyweight.
  - waruqi 8y ago
    Python also has version compatibility issues, such as: python2.x, 3.x. Also need the user to install the specified version of python
    - pfranz 8y ago
      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.
      - NikkiA 8y ago
        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.
        pfranz 8y ago
        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).
      - lasagnaphil 8y ago
        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.
        pfranz 8y ago
        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.
    - geezerjay 8y ago
      > 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.
      - rusk 8y ago
        > just create a virtual environment Yaw super lightweight ...
        geezerjay 8y ago
        Actually it is, but nevertheless that's only required by those who for some reason still believe today that python2 vs python3 is an issue.
        roel_v 8y ago
        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.
        rusk 8y ago
        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!
    - stuaxo 8y ago
      Pretty much everything has moved to Python 3 now.
- jandrewrogers 8y ago
  I can't think of a context in which I've used Meson where it ever felt not lightweight. Python is already installed in every system and ninja is quite small.
  - flohofwoe 8y ago
    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.
    - jcelerier 8y ago
      ninja on windows just requires you to download ninja.exe and put it in your path
    - nickez 8y ago
      python and ninja are also bundled in the installer for meson.
ridiculous_fish 8y ago
Why migrate from CMake to meson?
- jandrewrogers 8y ago
  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.
  - geezerjay 8y ago
    Cmake has tooling and is supported by IDEs. Does Meson have anything comparable?
    - jschwartzi 8y ago
      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.
      - geezerjay 8y ago
        > 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.
        bluGill 8y ago
        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.
pfultz2 8y ago
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.
- waruqi 8y ago
  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")
- geezerjay 8y ago
  > a way to tell it where your dependencies are installed(like cmake’s CMAKE_PREFIX_PATH). 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.
  - humanrebar 8y ago
    That's not entirely true, CMAKE_PREFIX_PATH is used in find_package and find_library calls.
rienbdj 8y ago
The Cmake migration tools are not very good. Meson has no glob support. Meson does not support any form of remote caching.
flohofwoe 8y ago
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.
- philpem 8y ago
  It's pretty easy to install Python on Mac (use Brew) or Windows (use WinPython), and most Linux distros include it by default... running an installer is hardly an onerous task.
- alexeiz 8y ago
  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).
sandGorgon 8y ago
what about Bazel ? https://bazel.build/ https://bazel.build/
- IshKebab 8y ago
  Bazel is very slow and heavy and only Google uses it.
  - rienbdj 8y ago
    In my benchmarks Bazel was the fastest of the lot, including Meson with Ninja.
    - laurentlb 8y ago
      Did you publish your benchmarks anywhere?
  - emidln 8y ago
    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.
blattimwind 8y ago
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.
NikkiA 8y ago
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.

waruqi 8y ago

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

shaklee3 8y ago
Python is preinstalled on any major Linux distro. Ninja is tiny, so those don't seem that heavyweight.
- waruqi 8y ago
  Python also has version compatibility issues, such as: python2.x, 3.x. Also need the user to install the specified version of python
  - pfranz 8y ago
    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.
    - NikkiA 8y ago
      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.
      - pfranz 8y ago
        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).
    - lasagnaphil 8y ago
      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.
      - pfranz 8y ago
        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.
  - geezerjay 8y ago
    > 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.
    - rusk 8y ago
      > just create a virtual environment Yaw super lightweight ...
      - geezerjay 8y ago
        Actually it is, but nevertheless that's only required by those who for some reason still believe today that python2 vs python3 is an issue.
        roel_v 8y ago
        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.
        rusk 8y ago
        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!
  - stuaxo 8y ago
    Pretty much everything has moved to Python 3 now.
jandrewrogers 8y ago
I can't think of a context in which I've used Meson where it ever felt not lightweight. Python is already installed in every system and ninja is quite small.
- flohofwoe 8y ago
  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.
  - jcelerier 8y ago
    ninja on windows just requires you to download ninja.exe and put it in your path
  - nickez 8y ago
    python and ninja are also bundled in the installer for meson.

ridiculous_fish 8y ago

Why migrate from CMake to meson?

jandrewrogers 8y ago
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.
- geezerjay 8y ago
  Cmake has tooling and is supported by IDEs. Does Meson have anything comparable?
  - jschwartzi 8y ago
    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.
    - geezerjay 8y ago
      > 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.
      - bluGill 8y ago
        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.

pfultz2 8y ago

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.

waruqi 8y ago
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")
geezerjay 8y ago
> a way to tell it where your dependencies are installed(like cmake’s CMAKE_PREFIX_PATH). 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.
- humanrebar 8y ago
  That's not entirely true, CMAKE_PREFIX_PATH is used in find_package and find_library calls.

rienbdj 8y ago

The Cmake migration tools are not very good. Meson has no glob support. Meson does not support any form of remote caching.

flohofwoe 8y ago

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.

philpem 8y ago
It's pretty easy to install Python on Mac (use Brew) or Windows (use WinPython), and most Linux distros include it by default... running an installer is hardly an onerous task.
alexeiz 8y ago
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).

sandGorgon 8y ago

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

IshKebab 8y ago
Bazel is very slow and heavy and only Google uses it.
- rienbdj 8y ago
  In my benchmarks Bazel was the fastest of the lot, including Meson with Ninja.
  - laurentlb 8y ago
    Did you publish your benchmarks anywhere?
- emidln 8y ago
  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.

blattimwind 8y ago

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.

NikkiA 8y ago

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.