On 2014-02-27 01:38, Russ Allbery wrote:
> Peter Rosin <p...@lysator.liu.se> writes:
>> On 2014-02-27 01:20, Russ Allbery wrote:
>
>>> Wouldn't you name the variable FOO_FEATURE? In other words, I think
>>> the example in the Autoconf manual is not the best, but the
>>> functionality you need is there. I would rewrite the example as:
>>>
>>> AC_CACHE_CHECK([for m4 that supports indir], [ac_cv_path_M4_indir],
>>> [AC_PATH_PROGS_FEATURE_CHECK([M4_indir], [m4 gm4],
>>> ...
>>> AC_SUBST([M4], [$ac_cv_path_M4_indir])
>
>> That doesn't work, because then you can't shortcut the test with the
>> natural M4=/some/gnu/place/m4, you'd be forced to write M4_indir=...
>> instead. This is even worse than saving the ac_cv_path_FOO variable
>> during the AC_PATH_PROGS_FEATURE_CHECK macro, since it would be visible
>> to the end user.
>
> Good point. However, couldn't you just put:
>
> : ${ac_cv_path_M4_indir:=$M4}
>
> before the above code?
Good point. Or put
: ${M4_indir:=$M4}
just before AC_PATH_PROGS_FEATURE_CHECK... Ho humm, which is best? Do I
want to see (cached) when overriding in the environment? Or not?
All this is too easy to get wrong in my opinion, and the manual would
certainly benefit from some clarification. The source code comment for
AC_PATH_PROGS_FEATURE_CHECK in autoconf even has the wording "It is
recommended, but not required, that the user also use
AC_ARG_VAR([VARIABLE])", which certainly is not suggesting that one
should use FOO_FEATURE instead of just FOO as variable.
Cheers,
Peter
