5 ms·

There seems to be a kind of “network effect” here with CMake, considering how popular it is among C/C++ projects. Meson is more or less equivalent in the funct

There seems to be a kind of “network effect” here with CMake, considering how popular it is among C/C++ projects. Meson is more or less equivalent in the functionality it provides. There is also Gradle, but it doesn’t seem to have gained much traction outside of Android development. My personal favorite is Bazel (and others from the Blaze family of build systems). It uses a python-based language for describing build rules, an extensive documentation and developers that respond to issues. Among the downsides is the lack of proper dependency management which is critical for public, open source projects. There is also Nix which takes it even further, but it requires much more involvement from the developer.

milanove 6y ago
Waf is another interesting build system I've seen used in production. It's config is done with Python scripts, which is cool.
- MaxBarraclough 6y ago
  There's also Premake, [0][1] Buildout, Ninja, SCons, and no doubt there are others. qmake was recently deprecated. It would take a lot to persuade me to move away from CMake and to use something 'non-standard' that few developers are familiar with: * Excellent support for command-line builds on Unix * Excellent support for Visual Studio * Excellent cross-platform package-detection. (Acid test: Can it detect and link against OpenCL without me having to write my own cross-platform OpenCL-detection script?) * Excellent documentation, including clear and consistent best practices and design patterns * A sensible language, whether a scripting language or a declarative language. Must follow the principle of least astonishment and be relatively free of foot-guns. (CMake fails tragically on both counts.) [0] https://premake.github.io/ https://premake.github.io/ [1] https://en.wikipedia.org/wiki/Premake https://en.wikipedia.org/wiki/Premake
  - knorker 6y ago
    I can't speak for MSVC support, but to me CMake fails all other bullet points. especially cross-platform package detection. I haven't seen anything except autotools get this right.
    - MaxBarraclough 6y ago
      > especially cross-platform package detection I disagree here. CMake has working FindXyz modules for most major libraries. To write one of those modules is an exercise in soul-destroying tedium, but there's a pretty impressive body of existing modules out there, many of them officially bundled with CMake. When used correctly, both CMake and Autotools are capable of robust package-detection. Regarding point 1: CMake works pretty well on Unix, but it's a pity there's a runtime dependency on the CMake package. Autotools is much better in that particular regard: just about any Unix system can run a configure script, as it's just a plain old shell script. CMake certainly falls short on the final 2 points, as I rambled about at https://news.ycombinator.com/item?id=24203172 https://news.ycombinator.com/item?id=24203172 It's too late for me to edit my earlier comment, but here's another alternative to CMake for the list: Bazel.
      - tn1 6y ago
        > CMake has working FindXyz modules for most major libraries Unless you have that library installed anywhere that is not /usr/include Then you have to just hope and pray that there's some magic incantation that will make it find the right one (especially if your system-installed version is the wrong version and you'd really like to use the newer version you installed to $HOME)
        MaxBarraclough 6y ago
        Right, but it's always like this. If you're on Windows and you install Boost to C:\random\directory, it seems fair that CMake will require you to specify that directory manually. The alternative is to have a global database, like the Windows registry or like pkg-config (which I have to admit I don't know much about). Perhaps CMake could have better support for pkg-config, I don't know.
- slavik81 6y ago
  I used Waf before I tried CMake, and I found the latter much easier to understand. The CMake language is a mess, but the compilation model is simple.
jcelerier 6y ago
> Meson is more or less equivalent in the functionality it provides. but meson needs everything to be quoted which is frankly a gigantic PITA - like, look at that, there's more quoted stuff than anything else: https://mesonbuild.com/Generating-sources.html https://mesonbuild.com/Generating-sources.html
- MaxBarraclough 6y ago
  I've not used it, but that wouldn't bother me too much. It's far preferable to a language like Bash where you're permitted to omit quotes, but consequently it's a minefield to write scripts that can robustly handle strings containing whitespace (e.g. arbitrary file paths). The Ada philosophy has it right: readability and correctness far outweigh writeability.
  - jcelerier 6y ago
    > The Ada philosophy has it right: readability and correctness far outweigh writeability. Given the popular success of Ada I'm not sure I would call that "having it right" except in very specific circumstances
    - MaxBarraclough 6y ago
      There are various reasons Ada didn't take over the world, I'm not convinced that its emphasis on readability over writeability is one of them. Far more time is spent on maintaining code than on initial development, and anyway, typing speed isn't the bottleneck for writing new code. Code review? You're in the business of reading code. Fixing bugs? You're in the business of reading code. Modifying/extending/porting an existing codebase? You're in the business of reading code. If you're writing trivial single-use 'throwaway' code that needs no review, then readability doesn't much matter, but it's an important factor for just about all serious codebases. Of course, there's also the question of whether Ada's specific syntax really succeeds in being more readable. It makes extensive use of English words in ways that are sometimes awkward and unnatural. I'm not a fan of its and then / or else short-circuit operators, for instance, and think they should just have gone with something like C's && / || operators. Neither syntax is self-explanatory to someone who doesn't know the language, but at least C's syntax doesn't counterintuitively collide with English.

milanove 6y ago

Waf is another interesting build system I've seen used in production. It's config is done with Python scripts, which is cool.

MaxBarraclough 6y ago
There's also Premake, [0][1] Buildout, Ninja, SCons, and no doubt there are others. qmake was recently deprecated. It would take a lot to persuade me to move away from CMake and to use something 'non-standard' that few developers are familiar with: * Excellent support for command-line builds on Unix * Excellent support for Visual Studio * Excellent cross-platform package-detection. (Acid test: Can it detect and link against OpenCL without me having to write my own cross-platform OpenCL-detection script?) * Excellent documentation, including clear and consistent best practices and design patterns * A sensible language, whether a scripting language or a declarative language. Must follow the principle of least astonishment and be relatively free of foot-guns. (CMake fails tragically on both counts.) [0] https://premake.github.io/ https://premake.github.io/ [1] https://en.wikipedia.org/wiki/Premake https://en.wikipedia.org/wiki/Premake
- knorker 6y ago
  I can't speak for MSVC support, but to me CMake fails all other bullet points. especially cross-platform package detection. I haven't seen anything except autotools get this right.
  - MaxBarraclough 6y ago
    > especially cross-platform package detection I disagree here. CMake has working FindXyz modules for most major libraries. To write one of those modules is an exercise in soul-destroying tedium, but there's a pretty impressive body of existing modules out there, many of them officially bundled with CMake. When used correctly, both CMake and Autotools are capable of robust package-detection. Regarding point 1: CMake works pretty well on Unix, but it's a pity there's a runtime dependency on the CMake package. Autotools is much better in that particular regard: just about any Unix system can run a configure script, as it's just a plain old shell script. CMake certainly falls short on the final 2 points, as I rambled about at https://news.ycombinator.com/item?id=24203172 https://news.ycombinator.com/item?id=24203172 It's too late for me to edit my earlier comment, but here's another alternative to CMake for the list: Bazel.
    - tn1 6y ago
      > CMake has working FindXyz modules for most major libraries Unless you have that library installed anywhere that is not /usr/include Then you have to just hope and pray that there's some magic incantation that will make it find the right one (especially if your system-installed version is the wrong version and you'd really like to use the newer version you installed to $HOME)
      - MaxBarraclough 6y ago
        Right, but it's always like this. If you're on Windows and you install Boost to C:\random\directory, it seems fair that CMake will require you to specify that directory manually. The alternative is to have a global database, like the Windows registry or like pkg-config (which I have to admit I don't know much about). Perhaps CMake could have better support for pkg-config, I don't know.
slavik81 6y ago
I used Waf before I tried CMake, and I found the latter much easier to understand. The CMake language is a mess, but the compilation model is simple.

jcelerier 6y ago

> Meson is more or less equivalent in the functionality it provides. but meson needs everything to be quoted which is frankly a gigantic PITA - like, look at that, there's more quoted stuff than anything else: https://mesonbuild.com/Generating-sources.html https://mesonbuild.com/Generating-sources.html

MaxBarraclough 6y ago
I've not used it, but that wouldn't bother me too much. It's far preferable to a language like Bash where you're permitted to omit quotes, but consequently it's a minefield to write scripts that can robustly handle strings containing whitespace (e.g. arbitrary file paths). The Ada philosophy has it right: readability and correctness far outweigh writeability.
- jcelerier 6y ago
  > The Ada philosophy has it right: readability and correctness far outweigh writeability. Given the popular success of Ada I'm not sure I would call that "having it right" except in very specific circumstances
  - MaxBarraclough 6y ago
    There are various reasons Ada didn't take over the world, I'm not convinced that its emphasis on readability over writeability is one of them. Far more time is spent on maintaining code than on initial development, and anyway, typing speed isn't the bottleneck for writing new code. Code review? You're in the business of reading code. Fixing bugs? You're in the business of reading code. Modifying/extending/porting an existing codebase? You're in the business of reading code. If you're writing trivial single-use 'throwaway' code that needs no review, then readability doesn't much matter, but it's an important factor for just about all serious codebases. Of course, there's also the question of whether Ada's specific syntax really succeeds in being more readable. It makes extensive use of English words in ways that are sometimes awkward and unnatural. I'm not a fan of its and then / or else short-circuit operators, for instance, and think they should just have gone with something like C's && / || operators. Neither syntax is self-explanatory to someone who doesn't know the language, but at least C's syntax doesn't counterintuitively collide with English.