<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Mon, 2010-12-13 at 17:26 -0500, Trevor Woerner wrote: <BLOCKQUOTE TYPE=CITE> <TT>I have been using the --cache-file feature for years (on other</TT> <TT>projects, of course). Although I've never timed its operation, it</TT> <TT>certainly _seems_ to speed up the configuration process since,</TT> <TT>roughly, 90% or more of the variables are the same between all builds</TT> <TT>and don't need to be recalculated over and over again. For example,</TT> <TT>anytime configure.ac uses a built-in test (e.g. AC_PROG_YACC) the</TT> <TT>variables and the test will be the same, so it would only need to be</TT> <TT>calculated once, then the results could just be reused for all future</TT> <TT>such checks.</TT> <TT>I hadn't noticed it causing any build problems, but I'll keep an eye out for it.</TT> <TT>In the example you noticed, pkg_cv_XFT_LIBS, both packages are looking</TT> <TT>for the Xft library which they both get, xdm just includes a couple</TT> <TT>extra (which is probably not as efficient).</TT> </BLOCKQUOTE> I am glad you have experience with it because I don't. Let me explain better the problem I suspect there is with it. The example you gave about AC_PROG_YACC makes perfect sense. It is unlikely, and would be wrong, for some package to define a different variable also named AC_PROG_YACC. The cache variable would be confused, sometimes holding one value and sometimes another. Note that Autoconf have a convention of using AC_ as a namespace which helps prevent accidental name clashing. This will work just fine. In X.Org, we have over 240 packages which can define Automake variables. We have not adopted a namespace for X.Org variables, but we are careful not to step on someone else namespace. Within the scope of the 240 modules, it's free for all. There is no "per package" namespace. Let's use a different example to illustrate the problem. In the driver directory, there are 55 drivers using statements like this one: <BLOCKQUOTE> <PRE> PKG_CHECK_MODULES(XORG, [xorg-server >= 1.0.99.901 xproto fontsproto xf86dgaproto $REQUIRED_MODULES]) </PRE> </BLOCKQUOTE> The resulting variables XORG_CFLAGS and XORG_LIBS are unique to each package and hold different values. This is where I think the concept of a cache does not hold. The last write wins and if you pick a random package to rebuild, it will pick the value written last. I do not want to blame the feature, or anyone, but if it is not safe to use I'd rather remove it from build.sh to avoid someone getting burn by it. An expert can always use it anyway. </BODY> </HTML>