Re: please correct my ugly hack

[Stepan Kasal]

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