autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fyi-ac-arg-var.patch


From: Alexandre Oliva
Subject: Re: fyi-ac-arg-var.patch
Date: 21 Jun 2001 01:12:51 -0300
User-agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Academic Rigor)

On Jun 19, 2001, Akim Demaille <address@hidden> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <address@hidden> writes:
Alexandre> How about, instead of renaming config.cache, restarting
Alexandre> configure with a switch that causes it not to use
Alexandre> config.cache at all (i.e., don't read it, don't write it).
Alexandre> Or restarting it with a private config.cache, removed after
Alexandre> configure is completed.

> Doesn't sound to me either for the expert.  You're killing her
> Makefile, her config.h, and possibly cause a full recompilation.

Huh?  It's not killing anything at all.  The user started configure,
these files are going to be generated.  The difference is that they're
going to be configured and generated using the new environment.

> That's why I picked up the `user expert' solution.

Which happens to have a lot of potential to break for novices.

It seems to me that we should just bail out in case any of the
precious variables change, and be done with it.

> How about keeping `user expert', but in addition to the warning at the
> beginning of configure, putting one at the end, so end the user cannot
> miss it.

The user can still miss it.  S/he may have run `./configure && make'
(or `configure; make', since s/he's a novice :-) and then the warning
may go unnoticed.  Or s/he may be configuring/building
binutils+GCC+gdb+newlib, with their number of configure steps.

> How about introducing --force?

What would --force do?  I don't think reusing the cache when some
environment variable changes is ever going to be a good idea.  I could
agree with not reading the cache in, but writing it out just the
same.  After all, the cache is just a cache, so the only thing you're
going to lose by not reading it in is build time, and, but if you use
incorrect cached values, you're going lose more than build time.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me



reply via email to

[Prev in Thread] Current Thread [Next in Thread]