Hacker News Reader

Comment by kazinator | Hacker News Reader

With the release materials you won't see problems on mainstream distros doing configure && make && make install.

I'm talking about cloning the program's git repo and working with that.

GNU programs don't include the generated configure script in their repos; you have to boostrap that first, and you need all the AutoCruft, in the correct versions which that git baseline of the program wants.

It's completely insane. It should be that to create a release of gnu-whatever-1.2.3 you just create a tarball directly out of git using the 1.2.3 version tag. That is the release. But that's not how it works; a release that doesn't require AutoTools has to be specially prepared.

Sometimes I have cheated to build a GNU program from sources. I would find the closest matching release tarball and unpack it over the cloned git repo, then run ./configure and all that. Carefully git-reset any differences and so on.

View on HN

While what you said is true, for outsiders it misses the 'why' (which I'm sure you are aware of!).

The idea with autotools is that the generated configure script (and other assorted files) is supposed to be forwards and backwards compatible with different systems. It's not perfect, but the behaviour is mostly locked down at the time it is built, based on the particular set of macros it is generated with.

There are definitely aspects of this which don't work (it's nearly impossible to test, getting specific versions of autotools is presumably a PITA, and the make-in-bash-in-m4 language is deeply cursed), but the overall design does make some things better.

For example, if your project needs a specific version of cmake, your users will have to figure out how to install it, but if your project requires a specific version of autotools, only your developers need to install it.

(FWIW autotools is on my 'never again' list of technologies; it's incredibly cursed)

As long as your policies are set correctly (not that this is particularly easy), your project will only need a version of CMake or newer, not a specific version.

Yeah, they are quite good at compatibility. In practice there may often be an upper version limit if you happen to use any features which eventually get deprecated or removed.

You seem to have a lot of experience with some hairy stuff. Mine consists of creating some open source C projects using autotools, and also cloning / building perhaps 7 projects I frequently use on Ubuntu and popOS which I have not struggled with. But totally believe that autotools hell is widespread.

My total nightmare experience has been with CMake, with a project that mixed C and C++. IIRC it had to do with trying to get something to work on LLVM / macOS which it wasn't originally supported for.

To be clear, I'm dead set against CMake. I would never voluntarily agree with that being introduced anywhere for any purpose. The concept is bad and the implementation is atrocious. In no uncertain terms, CMake is harmful garbage.

I'm curious: do you mind being a bit more specific? Feel free to send an email (easily discoverable from Git commits I make and end up on Github; same handle here and there).

(FD: CMake developer) I certainly understand a lot of the gripes that people have had, but the amount of tribal knowledge for obscure platform behaviors encoded in CMake is…vast. I am certainly in the "things need to improve" camp, but I don't think burning all the bridges that have been built is the way to go either.

Reply on news.ycombinator.com