4 ms·

In my experience, CMake seems to be more capable and easier to work with, both for the package author and for the person trying to build it. Also, more flexible

In my experience, CMake seems to be more capable and easier to work with, both for the package author and for the person trying to build it. Also, more flexible in terms of how projects/packages depend on each other. Now CMake is certainly not great; it has a lot of warts and baggage; and some functionality is _not_ easy to use, like installation (you need a good hour of explanation to make heads from tails with that, and then you're supposed to write 4 or 5 different CMake commands even for the simple use-case of "just install my damn plain-vanilla library"). But I'll choose it over meson any day of the week, and so would my users (i.e. the people who download and build my packages).

wirrbel 4y ago
I really like automake and autoconf it’s not like I don’t know the shortcomings but with a routine (and good templates) it just works and works and works
- bonzini 4y ago
  I used to like autotools a lot and even contributed to them, but honestly since I started using Meson there has been no going back. It's not perfect and I do have three-four pet peeves that I hate about Meson, but they are more than offset by the overall ease of use and a feature set that matches pretty much what I need from a build system.
- einpoklum 4y ago
  1. How well is CUDA supported there, for example? 2. What about when your users are on Windows? 3. How easy is it to combine autotools projects?
  - wirrbel 4y ago
    1. dunno never used CUDA. Pretty sure you can hack something together but I am the first to admit that it will be a bumpy ride if you start from 0 2. depends on what you are building. My users run WSL so essentially Linux user space. 3. are you asking for interdependencies? It works in principle I would say, for an elaborate foolproof setup I would anyway use bazel or buck in such a situation.
    - einpoklum 4y ago
      > My users run WSL Ok, what if they weren't? We don't all get to make such calls for our users. Especially if we're writing libraries, which should be usable in Windows software development as well. This is a significant consideration for me in preferring CMake over autotools. > are you asking for interdependencies? It works in principle I would say, for an elaborate foolproof setup I would anyway use bazel or buck in such a situation. Ok, so - while I'm certain that in many cases, autotools is fine, your answers clarify how CMake is a better "swiss army knife". It caters to multiple modes of composition and inter-dependency: build-install-then-find_packages; download dependencies and build during dependent project configuration step; download dependencies and build during dependent project build step; manage dependencies via packager manager (e.g. conan and probably vcpkg); etc. Now, some of these require a bit of care to get right; but they're all tried-and-true. And again, this will work on both Unix-like and Windows-like platforms.
- IshKebab 4y ago
  Autotools is the most portable build system... if you ignore the most popular desktop OS in the world.
tristan957 4y ago
Can you give any reasons for being "more capable and easier to work with?" I don't see how it is easier for users since as far as I am aware pkg-config files are an after-thought in CMake and options are all over the place (no equivalent of b_lto, default_libary, b_sanitize, etc.) so you have to learn about each project's non-standard equivalent options. What is hard about the following for users? meson setup build <build options...> ninja -C build ninja -C build install
- jcelerier 4y ago
  > (no equivalent of b_lto, default_libary, b_sanitize, etc.) so you have to learn about each project's non-standard equivalent options. regarding this, I developped a wrapper for CMake a few years ago and never looked back: https://github.com/jcelerier/cninja https://github.com/jcelerier/cninja
- einpoklum 4y ago
  > What is hard about the following for users? The ninja part is the same for CMake and for meson, but let's look at the meson command: > meson setup build <build options...> Except that when you try to specify build options, you will often fails, because some of them are "core options" and some of them are "base options" and some are "universal options" and their syntax is different. Sometimes. See, e.g.: https://stackoverflow.com/q/63549328/1593077 https://stackoverflow.com/q/63549328/1593077
  - germandiago 4y ago
    Oh you seem to talk as if the option/set CMake mess was not one hundred times messier.
    - einpoklum 4y ago
      It's only (somewhat) messy for the person writing the CMakeLists.txt, not for the person building. Which is what I was saying.
      - 4y ago
jeltz 4y ago
As someone who usually builds things I disagree. I think autotools is easiest followed by Meson and with the most annoying build system being CMake. On the other hand when I have to write build scripts I think Meson is best followed by CMake and then autotools. I feel Meson is a good compromise between maintainer needs and end user (the guy who build the project) needs.
stefan_ 4y ago
There is a bizarre subset of programmers that confuse having to manually specify input flags based on individually targeted compiler with a "more capable" build system. Fuck no, it's the opposite of why I wanted a build system in the first place.
- einpoklum 4y ago
  1. I'm not part of that bizarre subset of programmers... 2. CMake generates build systems (or build system scripts), it's not a build system in itself. After this generation (called the CMake configure phase), you use the generated build script with the build system of choice (ninja, GNU Make, vcbuild, etc.)

wirrbel 4y ago

I really like automake and autoconf it’s not like I don’t know the shortcomings but with a routine (and good templates) it just works and works and works

bonzini 4y ago
I used to like autotools a lot and even contributed to them, but honestly since I started using Meson there has been no going back. It's not perfect and I do have three-four pet peeves that I hate about Meson, but they are more than offset by the overall ease of use and a feature set that matches pretty much what I need from a build system.
einpoklum 4y ago
1. How well is CUDA supported there, for example? 2. What about when your users are on Windows? 3. How easy is it to combine autotools projects?
- wirrbel 4y ago
  1. dunno never used CUDA. Pretty sure you can hack something together but I am the first to admit that it will be a bumpy ride if you start from 0 2. depends on what you are building. My users run WSL so essentially Linux user space. 3. are you asking for interdependencies? It works in principle I would say, for an elaborate foolproof setup I would anyway use bazel or buck in such a situation.
  - einpoklum 4y ago
    > My users run WSL Ok, what if they weren't? We don't all get to make such calls for our users. Especially if we're writing libraries, which should be usable in Windows software development as well. This is a significant consideration for me in preferring CMake over autotools. > are you asking for interdependencies? It works in principle I would say, for an elaborate foolproof setup I would anyway use bazel or buck in such a situation. Ok, so - while I'm certain that in many cases, autotools is fine, your answers clarify how CMake is a better "swiss army knife". It caters to multiple modes of composition and inter-dependency: build-install-then-find_packages; download dependencies and build during dependent project configuration step; download dependencies and build during dependent project build step; manage dependencies via packager manager (e.g. conan and probably vcpkg); etc. Now, some of these require a bit of care to get right; but they're all tried-and-true. And again, this will work on both Unix-like and Windows-like platforms.
IshKebab 4y ago
Autotools is the most portable build system... if you ignore the most popular desktop OS in the world.

tristan957 4y ago

Can you give any reasons for being "more capable and easier to work with?" I don't see how it is easier for users since as far as I am aware pkg-config files are an after-thought in CMake and options are all over the place (no equivalent of b_lto, default_libary, b_sanitize, etc.) so you have to learn about each project's non-standard equivalent options. What is hard about the following for users? meson setup build <build options...> ninja -C build ninja -C build install

jcelerier 4y ago
> (no equivalent of b_lto, default_libary, b_sanitize, etc.) so you have to learn about each project's non-standard equivalent options. regarding this, I developped a wrapper for CMake a few years ago and never looked back: https://github.com/jcelerier/cninja https://github.com/jcelerier/cninja
einpoklum 4y ago
> What is hard about the following for users? The ninja part is the same for CMake and for meson, but let's look at the meson command: > meson setup build <build options...> Except that when you try to specify build options, you will often fails, because some of them are "core options" and some of them are "base options" and some are "universal options" and their syntax is different. Sometimes. See, e.g.: https://stackoverflow.com/q/63549328/1593077 https://stackoverflow.com/q/63549328/1593077
- germandiago 4y ago
  Oh you seem to talk as if the option/set CMake mess was not one hundred times messier.
  - einpoklum 4y ago
    It's only (somewhat) messy for the person writing the CMakeLists.txt, not for the person building. Which is what I was saying.
    - 4y ago

jeltz 4y ago

As someone who usually builds things I disagree. I think autotools is easiest followed by Meson and with the most annoying build system being CMake. On the other hand when I have to write build scripts I think Meson is best followed by CMake and then autotools. I feel Meson is a good compromise between maintainer needs and end user (the guy who build the project) needs.

stefan_ 4y ago

There is a bizarre subset of programmers that confuse having to manually specify input flags based on individually targeted compiler with a "more capable" build system. Fuck no, it's the opposite of why I wanted a build system in the first place.

einpoklum 4y ago
1. I'm not part of that bizarre subset of programmers... 2. CMake generates build systems (or build system scripts), it's not a build system in itself. After this generation (called the CMake configure phase), you use the generated build script with the build system of choice (ninja, GNU Make, vcbuild, etc.)