> Building the cache key will indeed be the difficult part. Even for a > single project, using different toolchains or targets will definitely > have different results. > [...] > Coalescing tests is also the approach taken by this proposal to CMake: > > https://gitlab.kitware.com/cmake/cmake/-/work_items/27945 > > I've also been considering async/await for such things so that > independent tests can at least be run concurrently.
Yes. I entirely agree that we should probably eventually start running conftests in parallel and introduce the test coalescing. Since I became a maintainer for the GNU automake project recently, autoconf has also been on my mind. Perhaps I will try to implement something and propose it soon-ish. -- With Valediction, Kamila Szewczyk (https://iczelia.net) On 8/19/26 3:27 PM, Ben Boeckel wrote: > On Wed, Aug 19, 2026 at 10:24:57 +0200, Kamila Szewczyk wrote: >> In order to stop myself from reconfiguring often, which is admittedly >> very slow, I add `build-*' to my gitignore and have a handful of >> directories (i.e. `build-b64', `build-ubsan', so on and so forth) for >> different builds. > > Similar here, though I use sibling directories rather than children: > > project/src # main repo > project/src-related # a related repo (or worktree) > project/build # main build for /src > project/build-related # a specific build tree (either variant or for a > different source tree > >> autoconf does cache a handful of things, but the environment could >> change across runs and thus render the cache stale without a clear way >> to invalidate it. The key question to answer is also what such cache >> would be keyed on in the first place. > > Building the cache key will indeed be the difficult part. Even for a > single project, using different toolchains or targets will definitely > have different results. > >> I think that one promising avenue to speeding up autoconf is >> parallelisation of its conftests and fast-paths engineered for modern >> systems. Another option would be more diligent recording inside >> config.status to then coalesce tests. For example, if we know that >> stdio.h, stdlib.h, and string.h are present, they could be all used at >> once in a unit to create a fast path for probing, with granular checks >> if this fast path fails. > > Coalescing tests is also the approach taken by this proposal to CMake: > > https://gitlab.kitware.com/cmake/cmake/-/work_items/27945 > > I've also been considering async/await for such things so that > independent tests can at least be run concurrently. > > --Ben
OpenPGP_0xC868F0B6DE38409D.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
