[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fyi-ac-arg-var.patch
From: |
Akim Demaille |
Subject: |
Re: fyi-ac-arg-var.patch |
Date: |
18 Jun 2001 09:11:45 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) |
>>>>> "Alexandre" == Alexandre Oliva <address@hidden> writes:
Hi Alexandre.
Alexandre> And why would this be wrong? I mean, the cached test
Alexandre> results are consistent with the cached environment
Alexandre> variables values. If you just modify the cached env vars,
Alexandre> you're creating an inconsistent cache. I strongly disagree
Alexandre> with this change.
Well, OK, but first I hope you agree the previous situation was dead
wrong. As a matter of fact, I know this `bug' (in my sense) from the
inception of AC_ARG_VAR but never took time to fix it :(
The bug is simply that then, anyway, the current value of $PRECIOUS is
used through out configure, and config.status is rebuilt anyway, using
a mix between old and new values. What was not acceptable was having
configure think one thing about PRECIOUS, and the cache believing
something else. The two of them must agree, the latter must reflect
the former.
Two implementations:
- the user is a novice
then if there are changed PRECIOUS vars, specify which ones, and
abort.
- the user is an expert
warn if appropriate, but do what she says, and cache the latest
values.
I discarded these choices:
- configure is an expert
if the user specify PRECIOUS=new, but before PRECIOUS was `old',
then force PRECIOUS=old.
I don't like this one, because it is somewhat unlikely that only
PRECIOUS changed, so anyway the build will be bad, and in addition,
I don't like configure believing it knows better than the user.
- configure is broken
if PRECIOUS is now `new', then warn, cache results depending upon
`new' and `old', and save the fact that PRECIOUS was `old' (not `new').
Let's reach quickly an agreement for 2.51. If you don't like `user
expert', how about `user novice'? I like it better than the former,
but meant to implement it when I made `configure broken'.
- fyi-ac-arg-var.patch, Akim Demaille, 2001/06/17
- Re: fyi-ac-arg-var.patch, Alexandre Oliva, 2001/06/17
- Re: fyi-ac-arg-var.patch,
Akim Demaille <=
- Re: fyi-ac-arg-var.patch, Alexandre Oliva, 2001/06/19
- Re: fyi-ac-arg-var.patch, Akim Demaille, 2001/06/19
- Re: fyi-ac-arg-var.patch, Alexandre Oliva, 2001/06/19
- Re: fyi-ac-arg-var.patch, Akim Demaille, 2001/06/19
- Re: fyi-ac-arg-var.patch, Akim Demaille, 2001/06/19
- Re: fyi-ac-arg-var.patch, Pavel Roskin, 2001/06/20
- Re: fyi-ac-arg-var.patch, Akim Demaille, 2001/06/21
- AC_SYS_RESTARTABLE_SYSCALLS (was: fyi-ac-arg-var.patch), Pavel Roskin, 2001/06/22
- Re: AC_SYS_RESTARTABLE_SYSCALLS (was: fyi-ac-arg-var.patch), Pavel Roskin, 2001/06/25
- Re: AC_SYS_RESTARTABLE_SYSCALLS (was: fyi-ac-arg-var.patch), Akim Demaille, 2001/06/26