Re: misleading output from AC_PROG_AWK

[Ralf Wildenhues]

Hello Clint, Ben,

apologies for the long delay.

* Ben Pfaff wrote on Sat, Apr 26, 2008 at 10:13:58PM CEST:
> I'm passing along the following bug report that was reported
> against the Debian package for Autoconf 2.61.  I've looked over
> the Autoconf git repository and I don't see any changes in this
> area since 2.61.
> 
> This really is a generic cosmetic issue with AC_CHECK_PROGS: if
> the first binary tested for is not the most generic name for the
> program, then assigning to the overriding variable will seem to
> find that first binary instead of the generic program.
> 
> Clint Adams <address@hidden> writes:
> > I want @AWK@ to be equal to 'awk' so it will not introduce an
> > unnecessary dependency on whichever of gawk, mawk, or nawk it
> > finds first in the buildd chroot.  Therefore I am forced to
> > pass AWK=awk to configure, which then provides the following
> > output.
> >
> > checking for gawk... awk
> > checking whether make sets $(MAKE)... yes
> > checking for gawk... (cached) awk
> >
> > In this case, awk is not gawk, and configure is not actually
> > searching for gawk, so this AC_PROG_AWK output is misleading.

There are two slightly different issues in this report.

First, './configure' (without AWK=... setting) may print
| checking for gawk... awk

because it did not find gawk, mawk, nawk.  This is slightly confusing.
What are the alternatives?

- output a line for each name we check, or even each directory?
  Both is waaay too verbose; AC_PROG_FC, for example, checks for
  something like two dozen names.
- "checking for AWK" or (shudder) "checking for @AWK@"?  Hmm.
- adding new macro arguments to override what's printed?
  IMVHO not worth the hassle in this case.

I don't think changing the code for this issue is worth the drawbacks.

Second, in your case, './configure AWK=awk', checking is not done at
all.  I see the point that there is a difference between "configure
searched for this program before, but did not find it, so used this
alternative instead" and "the user overrides the search algorithm with
this value".  We could change it to output something like

| checking for gawk... (user-provided) awk

One drawback is that this may be wrong, too, for example when AWK
is passed from one configure script to the next (maybe "(set in $AWK)"
instead?).

As a workaround you could use
  ./configure ac_cv_prog_AWK=awk

which would give you
| checking for gawk... (cached) awk

which might be somewhat of a compromise.

Cheers, and thanks for the report,
Ralf