[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: misleading output from AC_PROG_AWK
From: |
Ralf Wildenhues |
Subject: |
Re: misleading output from AC_PROG_AWK |
Date: |
Fri, 20 Jun 2008 21:40:03 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Hi Eric,
* Eric Blake wrote on Fri, Jun 20, 2008 at 02:08:46PM CEST:
> According to Ralf Wildenhues on 6/19/2008 11:42 AM:
>> | 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?).
>
> Now that seems like a relatively simple idea. So the possible output
> cases would be:
>
> user did nothing, and awk is the final program found after a full search:
> | checking for gawk... awk
>
> user did nothing, and the cache was used:
> | checking for gawk... (cached) awk
>
> user supplied AWK:
> | checking for gawk... (set in $AWK) awk
>
> Here's where to stick a one-liner patch that would do this (although I
> haven't tested it, so it may need some quoting adjustments, and certainly
> needs a testsuite addition); does this approach sound good enough to
> pursue further?
Well, it needed a backslash before the first $. Let's look at a first
practice test:
$ ../autoconf/configure -C M4=/usr/bin/m4 EMACS=emacs \
EXPR=/usr/bin/expr PERL=/usr/bin/perl
| configure: creating cache config.cache
[...]
| checking for expr... /usr/bin/expr
| checking for GNU M4 that supports accurate traces... /usr/bin/m4
| checking how m4 supports trace files... --debugfile
| checking for perl... /usr/bin/perl
| checking for emacs... (set in $TEST_EMACS) emacs
| checking whether emacs is sufficiently recent... yes
| checking for emacs... (set in $EMACS) emacs
[...]
Hmm. M4, EXPR, and PERL are not designated at all, and mention of
TEST_EMACS is confusing at best. As much as I liked the initial idea,
the result of this isn't too good yet. With improved output, the user
will come to expect consistency in the improvement as well; and that
both requires more work in Autoconf, as well as work on the part of the
configure.ac author as well.
I haven't yet thought through whether this is fixable nicely or not.
Cheers, and thanks for your valuable input,
Ralf