Wsrtjtyk

After I run the configure script, I get a series of output which says "cached". For example:

checking for gcc... gcc

checking for gcc... (cached) gcc

...

checking dependency style of gcc... gcc3

checking dependency style of gcc... (cached) gcc3

Why is it outputting gcc twice here: one with "gcc" and the other "(cached) gcc"? It appears that the script is doing two checks. I thought the script would just check the cache for variables to speed up execution.

Also, where are these cached files stored? According to the autoconf documentation, it says:

By default, configure uses no cache file, to avoid problems caused by accidental use of stale cache files.

So it seems certain "checks" do get cached by the configure script by default. I have tried running "--config-cache", and the file "config.cache" get created.

I also ran this in my configure script:

# optimization flags

if test "x$ac_cv_prog_gcc" = xyes; then

   AC_MSG_CHECKING([AC_CV_PROG_GCC])

   AC_MSG_RESULT("$ac_cv_prog_gcc")

fi

The variable "ac_cv_prog_gcc" is nowhere to be found in config.cache though, so I am assuming these cached variables are stored elsewhere. Where are these files located?

Why is it outputting gcc twice here: one with "gcc" and the other
"(cached) gcc"? It appears that the script is doing two checks.

The script encounters two requests for the same check. It is smart enough to remember the result of the first one instead of performing an actual check the second time around. Because it does so, it reports the second time around that the result was drawn from its result cache instead of computed de novo. Even if it is not recording a cache file, it has an in-memory result cache for the duration of the script's run.

It cannot, in general, altogether suppress duplicate checks, because there is often code associated with a check to process the result, and that's not necessarily the same code for each of the redundant checks.

I
thought the script would just check the cache for variables to speed
up execution.

Yes, that's exactly what it is doing. And it is reporting that it has done so, and the result. This informs you in the event that it uses a value cached during a previous run, or manually entered into the cache, and it can alert you in the event that the cache is manipulated between checks. In the event that configure fails, it may also help you better track where the failure occurred.

Also, where are these cached files stored? According to the autoconf
documentation, it says:

By default, configure uses no cache file, to avoid problems caused by accidental use of stale cache files.

So it seems certain "checks" do get cached by the configure script by
default.

No checks get cached persistently by default. Every result that is cached at all is cached at least for the duration of the configure run, however, and if you enable a cache file then it is used for persistent cache storage.

I have tried running "--config-cache", and the file
"config.cache" get created.

I also ran this in my configure script:

# optimization flags

if test "x$ac_cv_prog_gcc" = xyes; then

   AC_MSG_CHECKING([AC_CV_PROG_GCC])

   AC_MSG_RESULT("$ac_cv_prog_gcc")

fi

The variable "ac_cv_prog_gcc" is nowhere to be found in config.cache
though, so I am assuming these cached variables are stored elsewhere.

It's not clear to me what you expected to be accomplished by that. If you want to manually enter a value into the cache then you should use the AC_CACHE_VALUE or AC_CACHE_CHECK macro for that purpose. You not appearing to have done so, it is unsurprising that you didn't see the variables cached.

Additionally, it is a bit unclear how you are using the --config-cache option. That option and its siblings apply on a per-run basis to control whether a persistent cache is used (both read and written). The mere presence of a cache file, by any name, is not sufficient for your configure script to actually use it on any given run.

Where are these files located?

You're already looking at it. It you use the --config-cache or -C option to your configure script then the cache is stored in config.cache. If instead you use the --cache-file=XXX option, then the cache is stored in the file you name.

Overall, however, do be aware that (persistent) caching is probably not what you are looking for. If you are considering it for a particular need, then I would recommend asking directly about that need, in a separate question.