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 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.
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’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.