Question

运行configure脚本后，得到一系列输出，显示为“ cached”。例如：

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

为什么在这里两次输出gcc：一个带有“ gcc”，另一个带有“（（缓存的）gcc”）？该脚本似乎正在执行两项检查。我以为脚本只会检查缓存中的变量以加快执行速度。

此外，这些缓存的文件存储在哪里？根据autoconf文档，它说：

默认情况下，configure不使用任何高速缓存文件，以避免因意外使用过时的高速缓存文件而引起的问题。

因此，默认情况下，某些“检查”似乎确实会被配置脚本缓存。我尝试运行“ --config-cache”，并创建文件“ config.cache”。

我也在我的配置脚本中运行了此

# 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

尽管在config.cache中找不到变量“ ac_cv_prog_gcc”，所以我假设这些缓存的变量存储在其他位置。这些文件在哪里？

Answer 1

为什么在这里两次输出gcc：一个带有“ gcc”，另一个带有 “（缓存的）gcc”？看来该脚本正在执行两项检查。

该脚本遇到两个请求进行相同检查的请求。记住第一个结果而不是第二次进行实际检查就足够了。因为这样做，它第二次报告从结果缓存中提取结果，而不是从计算出的 de novo 中提取结果。即使未记录缓存文件，它在脚本运行期间仍具有内存结果缓存。

通常，它不能完全抑制重复检查，因为经常有与检查相关联的代码来处理结果，并且每个冗余检查不一定都使用相同的代码。

我以为脚本只会检查缓存中的变量以加快速度执行。

是的，这正是它的作用。它正在报告这样做的结果以及结果。这会在使用上次运行时缓存的值或手动将其输入缓存中时通知您，并且如果在两次检查之间对缓存进行了操作，则会提醒您。如果configure发生故障，它也可以帮助您更好地跟踪发生故障的位置。

此外，这些缓存的文件存储在哪里？根据autoconf   文档，上面写着：


默认情况下，configure不使用任何高速缓存文件，以避免因意外使用过时的高速缓存文件而引起的问题。


因此，某些“检查”似乎确实被配置脚本缓存为   默认。

默认情况下，永久不会缓存任何支票。但是，至少在configure运行期间都会缓存所有缓存的结果，并且，如果启用了缓存文件，则将其用于持久性缓存存储。

我尝试运行“ --config-cache”和文件   创建“ config.cache”。

我也在我的配置脚本中运行了此
# 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
在config.cache中找不到变量“ ac_cv_prog_gcc” 不过，所以我假设这些缓存的变量存储在其他位置。

我不清楚您希望通过该方法完成什么。如果要在缓存中手动输入一个值，则应使用the AC_CACHE_VALUE or AC_CACHE_CHECK macro。您似乎没有这样做，因此您没有看到缓存的变量也就不足为奇了。

此外，还不清楚您如何使用--config-cache选项。该选项及其同级项在每次运行时应用来控制是否使用持久性缓存（读取和写入）。无论任何名称，仅存在高速缓存文件都不足以让您的configure脚本在任何给定运行中实际使用它。

这些文件在哪里？

您已经在查看它。如果您在--config-cache脚本中使用-C或configure选项，则缓存存储在config.cache中。相反，如果您使用--cache-file=XXX选项，则缓存将存储在您命名的文件中。

总的来说，请注意(persistent) caching is probably not what you are looking for。如果您正在考虑满足特定需求，那么我建议您在一个单独的问题中直接询问该需求。

运行configure之后，缓存的变量存储在哪里？

1 个答案: