[Top][All Lists]

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

Re: Bug in gnulib-tools prevents bison from bootstrapping

From: Noah Misch
Subject: Re: Bug in gnulib-tools prevents bison from bootstrapping
Date: Fri, 31 Aug 2007 19:23:55 -0700
User-agent: Mutt/1.5.9i

On Fri, Aug 31, 2007 at 10:03:09AM -0700, Eric Blake-1 wrote:
> > I see no AC_SUBST(M4) in your patch, though.
> The AC_SUBST is implicit, via the AC_ARG_VAR.  So I only
> needed M4=$ac_cv_path_M4 after the program check.

Ah, yes.

> The only reason for MSG in my suggestion is because of the tie-in
> with AC_CACHE_VAL.  As I discovered, attempting:
>  AC_CACHE_CHECK([msg], [ac_cv_path_PROG],
>   [_AC_PATH_PROG_FEATURE_CHECK([PROG], [proga progb],
>     [feature-check])])
> might not set PROG, depending on the existence of the cache, even though
>   AC_CHECK_PROGS([PROG], [proga progb])
> always sets PROG.  If nothing else, in my earlier testing of the
> patch, I got confused when M4 was set the first time but not the
> second, before I added the explicit M4=$ac_cv_path_M4.
> What makes this awkward is that since FEATURE-TEST requires the
> manipulation of ac_cv_path_PROG to end the _AC_PATH_PROG_FEATURE_CHECK
> loop successfully, it does not make much sense to call
> _AC_PATH_PROG_FEATURE_CHECK outside of a cache context (which means
> there must not be any side effects, such as setting VARIABLE or using
> AC_SUBST([VARIABLE]); but users probably expect a macro with similar
> semantics to AC_CHECK_PROGS.  So my thought was to have a public macro
> wrap the cache check, in which case it needs a message.

Good points.  You're right; the macro should either cache and print a message,
or it should not cache, print no messages, and have no side-effects.

> The one other question I have come up with in the meantime is whether,
> if VARIABLE is already set, we should still run it through
> FEATURE-CHECK.  In the current implementation of AC_PROG_SED, if you
> run ./configure SED=/bad/sed, configure will blindly use /bad/sed,
> even though ./configure PATH=/bad:$PATH recognizes that /bad/sed fails
> the feature check.

Let's not second-guess the user.  It's nice to be able to easily override the
configuration heuristic when it gets in the way.

> How about the following two prototypes, then?
> #                             FEATURE-TEST, [ACTION-IF-NOT_FOUND],
> #                             [PATH=$PATH])

My inclination is to keep only this one, and to leave it to the user to AC_SUBST
the variable, if desired.

> #                                   FEATURE-TEST,
> #                                   [ACTION-IF-NOT-FOUND],
> #                                   [PATH=$PATH])

This one is a small convenience; we could do without it.

reply via email to

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