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

[Trevor Woerner]

On Mon, Dec 13, 2010 at 12:04 PM, Gaetan Nadon <memsize at videotron.ca> wrote:
> On Mon, 2010-12-13 at 11:11 -0500, Trevor Woerner wrote:
>
> Wouldn't that suggest there's a mistake in one or both of these settings?
>
> They're both looking in the same directory ($HOME/xorg/src/lib) so
> that's a good thing. But if clock only requires "-lXft" but xdm
> requires all of "-lXft", "-lXrender", and "-lX11" then maybe
> something's wrong with how both projects setup the "pkg_cv_XFT_LIBS"
> variable?
>
> The name of the variable is purely arbitrary. It means different things to
> different modules. I don't really understand how this Autoconf feature can
> be useful. Perhaps if the modules configuration is very vanilla, things like
> CC don't change so you get some benefit. Maybe there is something I don't
> understand.
>
> http://www.gnu.org/software/automake/manual/autoconf.html#Caching-Results
>
> It looks to me that this feature made the assumptions that there would be no
> name clashing. Thanks for looking into this, I need to be convinced it is
> safe to use.

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).