On Wed, Aug 19, 2026 at 4:22 AM Kamila Szewczyk <[email protected]> wrote: > > 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.
Hi Kamila, If you're diligent and understand autoconf very well, you can get a lot out of this approach. If you are like me and you find yourself doing `rm -rf build` as part of your workflow (I don't always do this, but more often than not I'm afraid of dirty situations, i.e. when I need to run autoreconf/autogen.sh prior, etc, so I want a clean slate), then the configure script can take some time. I also don't build for many platforms or anything like that, I build it while dev-testing/authoring code. I don't care for the checks because I know that my environment is good. Perhaps I should store config.cache outside of the build directory and reuse it. > That said, in a big C project, reconfiguring from scratch I see... > > ./configure 2.51s user 1.44s sys 104% cpu 3.770 total Stats for GNU Guile's configure script: real 1m21.267s user 0m48.425s sys 0m32.531s Quite long! -- Regards, Nikolaos Chatzikonstantinou
