[autoconf-conversion] New tools and multilibs fight with one another

Ian Lance Taylor ian at airs.com
Fri Jul 25 20:16:28 UTC 2003


Phil Edwards <phil at jaj.com> writes:

> It looks like some single-quotes are not being interpreted properly.

I think they are being interpreted properly--at least, they are being
interpreted in accord with the sh language definition.

autoconf is adding those single quotes to the values in
$ac_configure_args, in lines like this:
      ac_configure_args="$ac_configure_args$ac_sep'$ac_arg'"

However, when you then write code like
    for ac_arg in $ac_configure_args
the shell does parameter expansion on $ac_configure_args, and then
does field splitting on the result.  It does't pass the result of the
parameter expansion back through the quote recognition which is done
on the input, nor does any quote removal step apply.

That is why config-ml.in is getting messed up.  In fact, I think there
are similar problems in autoconf 2.57 itself, in AC_OUTPUT_SUBDIRS,
and I suspect that it would be possible to mess up autoconf with
carefully chosen environment variables.

There is one way to get the right thing to happen, which is the way
that autoconf mainly uses ac_configure_args: write it into a script,
and execute the script.  This effectivel forces the shell to run quote
recognition on the parameter expansion.

For example, with ac_configure_args set as above, something like this
should print the arguments one on each line:

cat >foo1.sh <<EOF
for a in ${ac_configure_args}
do
  echo \${a}
done
EOF
. foo1.sh

This rather awful trick could be used for the argument processing in
config-ml.in.

I can't think of anything else that would work.  Basically you need to
expand the parameter and then treat it as normal shell input for quote
processing.  As far as I know, the shell language doesn't support that
directly.

Ian



More information about the autoconf-conversion mailing list