Re: avoiding obsolete macros like AC_TRY_RUN

[Ralf Wildenhues]

Hello Bruno,

* Bruno Haible wrote on Thu, Sep 03, 2009 at 12:59:48AM CEST:
> I have three problems with your patch.

Four, I would say:  ;-)

0) You have been used to the old ways for a decade.

This may sound offensive, but isn't meant to be, really.  When new users
ask questions about quoting on autoconf lists, we tell them that they
should use

- use one level of quoting per macro argument depth, for normal code
  that may contain m4 macro expansion,

- two levels of quoting for any literal text that should not undergo
  m4 macro expansion and may contain paired brackets.

This is a fundamental, simple-to-remember rule.

The developers of Autoconf have historically made mistakes by adding
macros that would themselves contain double-quoting.  This is a problem
because now users have to remember rules like:

- for literal text, use two levels of quoting everywhere, except in the
  AC_TRY_* macros and in the AC_HELP_STRING macro; and if you use gnulib
  or macros that use gnulib, then also in the AC_LIB_HAVE_LINKFLAGS
  macro; and any macros that invoke those macros with your arguments.

Wow.  What an inconsistent rule to remember.  How would you document
this in a manual?  I don't see havelib.texi documenting this exception
from the rule documented in the Autoconf manual.  When using it myself,
I'd rather go back to changequote than having to remember the above,
because changequote at least is a hack that occurs *close* to the text
that needs the hack, not somewhere else.

Autoconf bit the bullet and deprecated these macros, and provided help
to get away from them with -Wobsolete.  Gnulib can do it, too!

I agree on the less-than-ideal naming of the AC_*_IFELSE macros.

>    Comparing AC_*_IFELSE with AC_TRY*:
>    Advantages of AC_*_IFELSE:
>      - More systematic. AC_TRY_LINK takes includes and function-body 
> arguments,
>        and AC_TRY_RUN a single argument.

- More systematic: the quoting semantics are *systematic*.

>      - Possibility to pass code that contains invocations of autoconf
>        macros (rarely used).

Let's turn this around: gnulib could easily factorize several files
that currently use literals only, into a work layer and one
implementation.  Then, macro expansion would be used more; once you
venture there, consistent quoting becomes more important.  Examples:
  ceil[dfl].m4
  exponent[dfl].m4
  floor[dfl].m4
  frexp.m4 frexpl.m4 (probably too many differences, just like
                      printf-frexp*.m4)
  isnan[fd].m4       (the other isnan*.m4 files are probably too different)
  round*.m4          (probably too different)
  trunk*.m4

A factorization of these would pass around program code that isn't a
m4-literal.

>      - Danger if a single level of quoting is used instead of double quoting:

Yeah, but since this occurs in several other places in Autoconf code as
well, the user has to remember to use double-quoting *anyway*.  Once the
user remembers this, it is *much* easier to remember having to do it
*everywhere* right beside the text that needs the double-quoting, than
having to remember that some macros do this for you and others don't,
and having the double-quoting occur far away from the text that contains
literal brackets.

>        Array declarations and array accesses get silently botched in that
>        case. The autoconf manual uses double-quoting in the examples of
>        AC_LANG_SOURCE and AC_LANG_PROGRAM, which is good. But some advocates 
> like
>        you propagate single-quoting.

I am using double-quoting in this patch, and elsewhere *where it
matters*.  I'll gladly drop the AC_LIB_HAVE_LINKFLAGS hunks, but as I
said above, I'd then recommend deprecating this API and replacing it
with a different one that has consistent quotation.

>      - Pitfall: It's easy to forget the invocation of AC_LANG_SOURCE, and then
>        autoconf generates code which will fail on many but not all platforms.

We should think about what we can do to address this, thanks for the
suggestion.

> 3) Indentation:

This is a straw-man.  I'll gladly fix indentation in any of my patches
in any way you like; just describe precisely what you want (it's all a
mere couple of editor macros away).


One other item you did not list in your comparison:

4) Users of your macros have to live with the constant set of warnings
about obsolete macro usage, and, in the case of AC_LIB_HAVE_LINKFLAGS,
with remembering the special macro expansion semantics.

Autotools (including gnulib) are already quite difficult to understand
for users.  Let's not make it more difficult for them!

Thanks,
Ralf