Hi Nikolaos, 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.
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. 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. That said, in a big C project, reconfiguring from scratch I see... ./configure 2.51s user 1.44s sys 104% cpu 3.770 total -- With Valediction, Kamila Szewczyk (https://iczelia.net) On 8/19/26 6:35 AM, Nikolaos Chatzikonstantinou wrote: > Hello list, > > A quick idea that came to mind: > > When I compile in my local machine, I often do `./configure -C` which > caches all of the test results. Could there be a flag that skips the > existence tests altogether? > > Alternatively, is it possible to have a common database of test > results that I can use amongst all of my projects? If so, wouldn't it > be advisable to generate this database for most checks and keep it in > your system? How often does a "check for getaddrinfo" change in a > system? >
OpenPGP_0xC868F0B6DE38409D.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
