Hello Claudio, On Wed, Jun 01, 2005 at 07:39:58AM -0700, Claudio Fontana wrote: > for NAME in cp du mv rm sh su mkdir rmdir bunzip2 > bzip2 compress gunzip gzip tar unzip zip > do > AC_PATH_PROG($NAME, $NAME, [no]) > done The problem with is that the AC_*PROG macros expect a literal as a parameter. I can see two ways to fix it: 1) Loop on the m4 level. m4_foreach([MY_Cmd], [cp,du,mv,rm,sh,su,mkdir,rmdir,bunzip2,bzip2,compress,gunzip,gzip,tar,unzip,zip], [AC_PATH_PROG([PRG_]MY_Cmd, MY_Cmd, [no])]) 2) Patch Autoconf. Fix autoconf/lib/autoconf/programs.m4 so that it uses AS_VAR_* (Similarly as in lib/autoconf/headers.m4.) Then your original code should work. This attitude has the advantage that the generated configure will be smaller. I think that the patch which would put AS_VAR_* to programs.m4 would present a useful general improvement. Paul, would you accept such a patch? > for NAME in cp du mv rm sh su mkdir rmdir bunzip2 > bzip2 compress gunzip gzip tar unzip zip > do > QNAME=$NAME > AC_PATH_PROG(QNAME, $NAME, [no]) > eval $NAME=$QNAME > unset ac_cv_path_QNAME > done Another topic: this hack has to clear cache. That's something I noticed before: AC_CHECK_PROG and caching. I think the caching is almost redundant here: - The variable itself is a cache, at least during one run of configure. - Negative results, which don't set the VAR, cannot be cached. And what you cache? Looking to all dirs in path. Yes, there are situations when visiting all dirs in path is slow. But such setup slows down the build, and we shouldn't try _too much_ trickery to repair this broken setup. And the caching can cause unwanted surprises; imagine this: AC_CHECK_PROGS([FOO], [foo fooie]) FOO= AC_CHECK_PROGS([FOO], [foo1 foo fooie]) If the first call was successful, it's pulled from the cache. If it wasn't, configure looks for foo1 first. Another example: AC_CHECK_PROGS([FOO], [foo fooie]) if test "$special" = yes; then FOO=special-foo else FOO= fi AC_CHECK_PROGS([FOO], [foo1 foo fooie]) (A sidenote: you might ask why would one write this code. Perhaps the first AC_CHECK_PROGS was part of a bigger macro earlier. And the `if' before the second AC_CHECK_PROGS is there because we shouldn't put macros inside `if', right. In any case, this code is not too weird, so it should work.) If FOO is set to special-foo, then the AC_CHECK_PROGS pulls the old value from the cache. But if FOO is set, AC_CHECK_PROGS shouldn't touch it! I thought about the problem for some time, and my impression is that the interaction with cache is not very clear here. I think the best solution is to drop caching from programs.m4. Caching was invented mainly for expensive tests which involve calling a compiler, which can be really slow. In most environments, _AS_WALK_PATCH is way quicker than gcc. Paul, will you buy this? Stepan Kasal _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
