AC_PATH_PROGS_FEATURE_CHECK results in namespace invasion
Hi! It's not possible to use AC_PATH_PROGS_FEATURE_CHECK with a cache variable that does not start with ac_cv_path_ which is bad since one project might check for a certain capability of tool foo, while some other project is interested in some completely orthogonal capability of that same tool foo. As written, it is very likely that both projects will use the cache variable ac_cv_path_FOO for orthogonal purposes, which is bad by design. Or have I misread something? (Yes, I know that I can save ac_cv_path_FOO someplace else for the duration of the AC_PATH_PROGS_FEATURE_CHECK macro, then extract my result, then restore ac_cv_path_FOO, but that's just too ugly) Cheers, Peter
Re: AC_PATH_PROGS_FEATURE_CHECK results in namespace invasion
Peter Rosin p...@lysator.liu.se writes: It's not possible to use AC_PATH_PROGS_FEATURE_CHECK with a cache variable that does not start with ac_cv_path_ which is bad since one project might check for a certain capability of tool foo, while some other project is interested in some completely orthogonal capability of that same tool foo. As written, it is very likely that both projects will use the cache variable ac_cv_path_FOO for orthogonal purposes, which is bad by design. 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]) -- Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/
Re: AC_PATH_PROGS_FEATURE_CHECK results in namespace invasion
On 2014-02-27 01:20, Russ Allbery wrote: Peter Rosin writes: It's not possible to use AC_PATH_PROGS_FEATURE_CHECK with a cache variable that does not start with ac_cv_path_ which is bad since one project might check for a certain capability of tool foo, while some other project is interested in some completely orthogonal capability of that same tool foo. As written, it is very likely that both projects will use the cache variable ac_cv_path_FOO for orthogonal purposes, which is bad by design. 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. Cheers, Peter
Re: AC_PATH_PROGS_FEATURE_CHECK results in namespace invasion
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?
--
Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/
Re: AC_PATH_PROGS_FEATURE_CHECK results in namespace invasion
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
Re: AC_PATH_PROGS_FEATURE_CHECK results in namespace invasion
On 2014-02-27 02:00, Peter Rosin wrote:
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?
I think : ${M4_indir:=$M4} is slightly better, because then
M4_indir=/gnu/stuff/m4 beats M4=/crappy/shit/m4 while
ac_cv_path_M4_indir=/goodness/m4 still trumps both of them.
But that's probably of little practical importance...
Cheers,
Peter
