<!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:<BR>
<BLOCKQUOTE TYPE=CITE>
    <TT><FONT COLOR="#1a1a1a">I have been using the --cache-file feature for years (on other</FONT></TT><BR>
    <TT><FONT COLOR="#1a1a1a">projects, of course). Although I've never timed its operation, it</FONT></TT><BR>
    <TT><FONT COLOR="#1a1a1a">certainly _seems_ to speed up the configuration process since,</FONT></TT><BR>
    <TT><FONT COLOR="#1a1a1a">roughly, 90% or more of the variables are the same between all builds</FONT></TT><BR>
    <TT><FONT COLOR="#1a1a1a">and don't need to be recalculated over and over again. For example,</FONT></TT><BR>
    <TT><FONT COLOR="#1a1a1a">anytime configure.ac uses a built-in test (e.g. AC_PROG_YACC) the</FONT></TT><BR>
    <TT><FONT COLOR="#1a1a1a">variables and the test will be the same, so it would only need to be</FONT></TT><BR>
    <TT><FONT COLOR="#1a1a1a">calculated once, then the results could just be reused for all future</FONT></TT><BR>
    <TT><FONT COLOR="#1a1a1a">such checks.</FONT></TT><BR>
    <BR>
    <TT><FONT COLOR="#1a1a1a">I hadn't noticed it causing any build problems, but I'll keep an eye out for it.</FONT></TT><BR>
    <BR>
    <TT><FONT COLOR="#1a1a1a">In the example you noticed, pkg_cv_XFT_LIBS, both packages are looking</FONT></TT><BR>
    <TT><FONT COLOR="#1a1a1a">for the Xft library which they both get, xdm just includes a couple</FONT></TT><BR>
    <TT><FONT COLOR="#1a1a1a">extra (which is probably not as efficient).</FONT></TT><BR>
    <BR>
</BLOCKQUOTE>
I am glad you have experience with it because I don't.<BR>
<BR>
Let me explain better the problem I suspect there is with it. The example you gave about<BR>
AC_PROG_YACC makes perfect sense. It is unlikely, and would be wrong, for some package<BR>
to define a different variable also named AC_PROG_YACC. The cache variable would be confused,<BR>
sometimes holding one value and sometimes another. Note that Autoconf have a convention<BR>
of using AC_ as a namespace which helps prevent accidental name clashing.<BR>
This will work just fine.<BR>
<BR>
In X.Org, we have over 240 packages which can define Automake variables. We have not adopted<BR>
a namespace for X.Org variables, but we are careful not to step on someone else namespace.<BR>
Within the scope of the 240 modules, it's free for all. There is no &quot;per package&quot; namespace.<BR>
<BR>
Let's use a different example to illustrate the problem. In the driver directory, there are 55 drivers<BR>
using statements like this one:
<BLOCKQUOTE>
<PRE>
PKG_CHECK_MODULES(XORG, [xorg-server &gt;= 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.<BR>
This is where I think the concept of a cache does not hold. The last write wins and if you pick a random <BR>
package to rebuild, it will pick the value written last.<BR>
<BR>
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<BR>
to avoid someone getting burn by it. An expert can always use it anyway.<BR>
<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>