[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

- the user is an expert
  warn if appropriate, but do what she says, and cache the latest

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

reply via email to

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