Hacker News Reader

Comment by Thev00d00 | Hacker News Reader

Or use anything else.

CMake or Meson have both learned the lessons of Autotools and so you dont need to subject yourself to them anymore.

I have been surprised at how good my CMake experience has been. CMake may have its warts but so far everything with a CMakeLists.txt that I have tried has worked out of the box

Yeah but they're not always installed on the random SBC you might be configuring, or an old incompatible version might be installed. And then I have to dig through the build system to figure out the right way to set prefix etc. cmake and meson should really have a way to output a configure script and Makefile...

> cmake and meson should really have a way to output a configure script and Makefile

`cmake .. -GMakefile` not enough for you?

I mean, for distribution, so that cmake is not required for a user to compile the project.

How is that gonna help on windows where there is no /bin/sh ?

Install cygwin or msys or WSL? Windows is unusuable otherwise :).

anyway, the particular case here is something like an academic computing cluster, where you don't have administrator access, and you want to compile some package that will install into some place like $HOME/project/usr. The system has no meson or bazel or scons and only some older version of cmake that may not meet the claimed minimum requirement of the random package you want to compile.

Or it's some SBC that you dare not upgrade the operating system on because you don't know if there is some breaking kernel change with some hardware interface.

Sure, locally installing a new version of cmake or some other build system is not too hard, but it's certainly additional friction.

> Sure, locally installing a new version of cmake or some other build system is not too hard, but it's certainly additional friction.

for cmake it's basically

    wget https://github.com/Kitware/CMake/releases/download/v3.20.0/cmake-3.20.0-linux-x86_64.tar.gz
    tar xaf cmake-3.20.0-linux-x86_64.tar.gz
    export PATH=$PWD/cmake-3.20.0/bin:$PATH

definitely simpler than installing cygwin, msys or wsl :-) (and some software requires cl.exe on windows anyways)

Meson is tremendous pain to bootstrap in hardware development projects, because you have to get so much of Python working first. CMake used to be easier to cross-compile to bootstrap a project, but it's getting harder every year. Autotools just keeps working, even if you don't have a c++ runtime.

> CMake used to be easier to cross-compile to bootstrap a project, but it's getting harder every year.

Why exactly is it getting harder?

CMake still comes with ./bootstrap.sh and basically just needs GCC and a couple base libs for TLS

So, what would you say what these tools have learned and taken from autotools, and what are the core ideas with which they were improving? I was looking around for a description of what the core ideas of CMake are and could not find much, except automating for platforms which are not Unix-y or POSIX.

CMake is marketed heavily, but not all things which are said about autotools are accurate. Here is a video from somebody from KitWare who compares autotools to CMake:

https://youtu.be/8Ut9o4OdSC0?t=459

In this section, he kind of complains about the number of files which are needed to use an autoconf install. But the thing is, almost all of these are generated files. So, one does not have to create them - they are created by autoconf, once, by the developer, and stored together with the rest of the source distribution for installation.

Then, in the seconds after, at

https://youtu.be/8Ut9o4OdSC0?t=582

he compares the speed of autoconf to CMake, and CMake comes out faster. But, well, this time, he also adds to the total time the time which is needed to run autoconf for the first time, which generates the above files. So, in practice, a developer which changes source files, or a user which installs a package, does not need to run the autoconf generation of the configure script, and a developer which does imporovements and testing in the source code also does not need to build the configure script each time. To sum up, at the one hand side, he counts the generated autoconf files into the number of files needed for a package, but then he counts again the generation time into the run time to use autoconf regularly. And this is a bit weird, because the configure script and the other files only have to be generated once when a change to the build system is made, not for install builds and not for normal development builds.

I agree that autoconf could run a tad faster and that generated files could be organized a bit tidier (it is possible to configure it so that it puts them into a subfolder). But I think the comparisonn in the video is a little bit biased.

And of course, a company needs to make money and sell its products, but if a presentation of a core product starts with such a biased comparison, it is not very convincing to me. Well, we'll see where CMake is in five years time - build systems are extremely complex and large things and need to account for a lot of stuff which is rarely used to work robustly, and then it is perhaps coming to an age where things like good architecture, good design, and clean code mattes. I am not worried that CMake does not manage to do highly automated builds for simple projects and happy paths in the most popular platforms, but how it copes with the hard stuff on which a lot of computing infrastructure depends. There is a good reason why most of this infrastructure stuff, be it the kernel, or things like glibc, or OpenSSL, is not made by companies.

Reply on news.ycombinator.com