[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?
>
> # AC_PATH_PROGS_FEATURE_CHECK(VARIABLE, PROGNAME-LIST,
> # 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.
> # AC_CACHE_PATH_PROGS_FEATURE_CHECK(VARIABLE, PROGNAME-LIST, MSG,
> # FEATURE-TEST,
> # [ACTION-IF-NOT-FOUND],
> # [PATH=$PATH])
This one is a small convenience; we could do without it.