| echo > test1
| testsrc=test1
| testdest=test2
| AC_CONFIG_LINKS($testdest:test1 test3:$testsrc, [],
| [testsrc=$testsrc
| testdest=$testdest])
> I.e., test3 is OK, but not test1.
There are two parts in it. One bug is this controversial use
of AC_CONFIG_LINKS, which I only introduced for symmetry
and to check whether the bug only involved one purpose or
both.
The other bug is that `./config.status test3' won't work,
while `CONFIG_LINKS=test3 ./config.status' or simply
`./config.status' will. This is indeed a bug and is because
the processing of command line arguments in config.status
must be after the evaluation of the INIT-CMDS; you can now:
- defer the processing of all command line arguments, including
for example --help, like in the patch I sent to autoconf-patches,
- or process options and defer the processing of the rest of the
command line, like in the patch that I sent you privately
(by mistake, I wanted to address autoconf-patches actually).
Note that allowing both ways to use AC_CONFIG_LINKS is a
breeze once you move the INIT-CMDS, since it is only a matter
of double-quoting instead of single-quoting the choice in
the command line parsing case statement.
I hope this clarification will help fixing the bug.
Paolo
