Hi Nikolaos, > If you're diligent and understand autoconf very well, you can get a > lot out of this approach.
Certainly. I would recommend it to non-experts nonetheless. > 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 think that this is mostly a product of an inefficient development cycle. Building from scratch is generally also very expensive and likely dwarfs `configure' time on larger projects. > 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. The checks only seldom ascribe a valuating judgement like `good' or `bad' by virtue of carrying a hard dependency, I find myself using the configure tests to probe for whether various optional and platform specific features can be enabled. -- With Valediction, Kamila Szewczyk (https://iczelia.net) On 8/19/26 4:48 PM, Nikolaos Chatzikonstantinou wrote: > 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! >
OpenPGP_0xC868F0B6DE38409D.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
