Eric Blake wrote:
> Yes, but it probably should not be named AC_TRY_EVAL ...
> Better than documenting variables would be designing a nicer macro
> interface that exposes what those variables are trying to get at. Every
> time we document a shell variable instead of an autoconf macro, we've
> locked ourself into a particular implementation, instead of hiding behind
> a stable API where we can tune for performance.
Makes sense. If you are to design a new set of macros for this, then
I would also pledge for an easier syntax.
> > ac_gcj_link="$GCJ $GCJFLAGS conftest.java --main=conftest -o conftest$ac_exeext"
> > AC_TRY_EVAL([ac_gcj_link])
I'd prefer to write simply
AC_TRY_COMMAND([$GCJ $GCJFLAGS conftest.java --main=conftest -o conftest$ac_exeext])
without having to assign the command to a variable first.
> > AC_TRY_EVAL(NM conftest.$ac_objext \| $lt_cv_sys_global_symbol_pipe \> $nlist)
> > AC_TRY_EVAL(_LT_TAGVAR(archive_cmds, $1) 2\>\&1 \| $GREP \" -lc \" \>/dev/null 2\>\&1)
I'd prefer to be able to write
AC_TRY_COMMAND([[$NM conftest.$ac_objext | $lt_cv_sys_global_symbol_pipe > $nlist]])
AC_TRY_COMMAND([[$]_LT_TAGVAR(archive_cmds, $1)[ 2>&1 | $GREP " -lc " >/dev/null 2>&1]])
without backslashing and without omitting the leading '$' upfront.
> Better than documenting variables would be designing a nicer macro
> interface that exposes what those variables are trying to get at.
Indeed, I have not seen assignments to ac_link or ac_compile, only their use.
It would be fine to have documented macros, say, AC_LINK_COMMAND and
AC_COMPILE_COMMAND, in a way that
AC_TRY_COMMAND([AC_LINK_COMMAND])
and
AC_TRY_COMMAND([AC_COMPILE_COMMAND])
work. (Note the single quoting here, as opposed to double quoting in the
examples above where commands are passed that should not be expanded.)
Bruno
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
