Comment by kazinator | Hacker News Reader

Comment by kazinator | Hacker News Reader

Parent Full thread

> It is possible to use autotools nowadays without losing your mind.

Only by punting the problems downstream.

"Oh, cross-compiling? Not my problem, ..."

GNU programs are the worst. Most of them you can't even build as a developer just by cloning their git repo and doing configure and make. When they ship a GNU program (e.g. GNU BIson or Make or whatever), there is a step that is done to produce the building version and that's what goes into the "official tarball" (now there is an antedeluvial practice right there).

To build as a deverloper working on the program, you have to run some "make boostrap" idiocy, which needs the correct version of AutoConf and AutoMake and whatevernot. Of course, every GNU program you boostrap wants different versions of these things, determined by what upstream is using.

Oh, git bisect to go backwards a few years? Different tools were used then; re-bootstrap with that ...

It's just insanity and AutoTools is at the heart of it.

I have found standard distros on relatively recent versions don't have issues with configure / make / make install, or at least issues I can solve fairly easily with googles

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.

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.

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.

The reason for the recent stability is that the Autotools have been essentially unmaintained for the past 15 years. When there were steady releases back in the early 2000s, we experienced regular incompatibilities and breakage. Today, there are occasional releases again, but the tools have painted themselves into a corner--it's almost impossible to make any change of note without breaking things.

Reply on news.ycombinator.com