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
