Hacker News Reader

Comment by saboot | Hacker News Reader

"As crufty as autotools is, nothing comes close to being a more robust build system."

I wish this were true. Getting cmake to do something off the wall like building static executable binaries is...frustrating.

I had high hopes for scons, but that turned into a quagmire. Any build system that's going to unseat autotools will need to obviate the need for almost all custom scripts. AKA, specify the 'what', and let the user apply a 'recipe' for the 'how'. Or something...if I knew what it was supposed to look like I'd build it.

Cmake missed a huge opportunity when they developed their own syntax. Ironically, Cmake was invented specifically[0] for a project that was embedding Tcl, which is what they should have done with Cmake, too (embed Tcl). Cmake can be really nice to use for simple projects, but for the cases it gets you 95% to where you want to be... So frustrating.

[0] https://en.wikipedia.org/wiki/CMake#History

It's not that difficult to get CMake to build a static binary.

  SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a")
  SET(BUILD_SHARED_LIBRARIES OFF)
  SET(CMAKE_EXE_LINKER_FLAGS "-static")

The bigger problems with building a static binary on Linux are that: 1. Most Linux distros don't install static versions of libraries. You can't link in a static library dependency that doesn't exist. 2. glibc can't "really" be linked statically because of the way it's designed. See here for the gory details: https://gcc.gnu.org/ml/gcc/1998-12/msg00083.html

Naturally, you have problems #1 and #2 with autotools or any other build system as well, since they aren't CMake problems.

Out of curiosity, what are the quagmire-ish aspects of scons? I've been using it for a while, and it hasn't seemed too bad, which probably means that I haven't run into them yet.

Scons itself isn't bad, but it's power is also it's downfall: the build script is an unrestricted Python file. I almost always find that something 'clever' has been stashed in the SConscript. Plus, everybody writes wrapper functions for the env.* stuff - meaning just about every project has a second, hidden codebase that you need to learn first.

Ah, got it. I'll admit that I tend to make build scripts that are a bit too complicated, due to the freedom of having a full language, but it is quite nice to have when needed. It does end up with build scripts that are far more flexible, though, not having read build scripts that others have written, I don't know how much of a cost there is to it.

In my experience as a distribution maintainer, cmake is a lot more painful to deal with.

A lot of large projects* I use were formally autotools, and now use CMake. CMake is by far easier to maintain and allows easier integration this code in other projects with dependencies. I will agree that the documentation isn't great, the only way I was able to use it meaningfully by understanding how larger established projects utilize it.

http://www-public.slac.stanford.edu/geant4/

https://root.cern.ch/drupal/

https://www.kde.org/

Reply on news.ycombinator.com