[PATCH modular 1/4] build.sh: remove CACHE env variable as it is not implementable

[Gaetan Nadon]

On Mon, 2010-12-13 at 17:26 -0500, Trevor Woerner wrote:

> I have been using the --cache-file feature for years (on other
> projects, of course). Although I've never timed its operation, it
> certainly _seems_ to speed up the configuration process since,
> roughly, 90% or more of the variables are the same between all builds
> and don't need to be recalculated over and over again. For example,
> anytime configure.ac uses a built-in test (e.g. AC_PROG_YACC) the
> variables and the test will be the same, so it would only need to be
> calculated once, then the results could just be reused for all future
> such checks.
> 
> I hadn't noticed it causing any build problems, but I'll keep an eye
> out for it.
> 
> In the example you noticed, pkg_cv_XFT_LIBS, both packages are looking
> for the Xft library which they both get, xdm just includes a couple
> extra (which is probably not as efficient).
> 

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:

        PKG_CHECK_MODULES(XORG, [xorg-server >= 1.0.99.901 xproto fontsproto xf86dgaproto $REQUIRED_MODULES])

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.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101213/5922cab4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101213/5922cab4/attachment-0001.pgp>