Speeding up autoconf with caching (2022) | Hacker News Reader

Speeding up autoconf with caching (2022)

jmmv.dev

26 pointsjmmv16 comments

Never confuse caching with precalculation. Caches can go away while being used, or show up too late, leading to strange timing and shared state issues. A precalculated list is static. It is a knowable quantity.

It’s very much like the DRY problem where you take two pieces of similarly shaped code with different purposes and merge them, creating problems later on. They look the same, but they exist for very different reasons and do not conflate them.

If there’s a set of questions that most configure calls are bound to make, you can work those out at first run or install time. Install time gets weird with system and hardware upgrades.

I wonder if one of these coding assistant things could be trained to port autotools to cmake [1]? That is, finally transition away from it.... autotools is cryptic and slow and this cacher is 20 years old and hasn't caught on.

Or alternatively, could the coding assistant be trained to /simplify/ the autotools config to remove all the obsolete tests and make it fast and short?

[1 or meson or whatever the leading alternative is.

My experience with autotools projects is that more often than not it ends up being a collection of arcane commands and painstaking minutiae that probably nobody fully understands but somehow ends up calling the right commands to compile the program. So, you're going to need ASI to work with that.

configure is slow enough, but autoreconf is awwwwfullll. Obviously most people don't need to run it that often, but even right now I'm working on a project where I'm making a lot of related-but-separate changes that I want in different commits. So I have three commits at the top of my branch right now, and I'm constantly writing a bunch of code, then using 'git add -p' to stage some parts of it, but not all, and then amending one of those three commits. The second commit has some changes to configure.ac, so every time I amend the commit before it, the timestamps change, and the makefile believes configure is older than configure.ac and that autoreconf needs to be rerun.

Although I guess I could just follow my commit amend with a 'touch configure' (and maybe a 'find . -name Makefile -exec touch \{\} \;' for good measure) and that might solve the problem...

I could have sworn that config.cache used to be on by default. And indeed it was until autoconf-2.50 which was released in 2001.

Interesting; do you know / did they document why it was disabled?

I couldn't find an explanation but my guess is that it probably had some edge case failures (like corrupt files after an abort) or it didn't invalidate the cache when autoconf or environment changes affected the test results.

I used to have a wrapper that tried to use a shared config.cache across all projects but I stopped using it around the same time. I can't remember my personal reasons either but must have been something like the above.

Thanks for sharing. I've been meaning to learn to use autoconf; autoconf caching and your autoswc tool seem really useful!

They not yet discovered Site Defaults and config.site

There's a way to make autoconf infinitely faster: get rid of it. CMake is a lot better, but still terrible, get rid of it too while you're at it.

pkg-config seems like all you need these days

Maybe the next backdoor can be in a prepopulated cache file instead of the autoconf script!

CMake does not fare better either!

IME, it does. It takes 1-2 seconds for small projects and under 20 for most large ones.

I’ve unfortunately encountered cmake projects which take upwards of a minute to configure. It has a faster baseline but it can’t stop you from writing slow checks.

It should be 0. It should never query this to begin with.

Reply on news.ycombinator.com