Re: AC_COMPILE_IFELSE

[Bruno Haible]

Hello Ralf,

I wrote:
> > AC_TRY_COMPILE has a more mnemonic name (it follows the
> > usual rule to use an English verb to as a function/macro name)
> > and simpler quoting rules than AC_COMPILE_IFELSE.

Also, AC_COMPILE_IFELSE presents a pitfall: One is tempted to write

    AC_COMPILE_IFELSE([
      #include <blabla.h>
      int main () { do_foobar (); }
    ], ..., ...)

forgetting about AC_LANG_PROGRAM. AC_COMPILE_IFELSE does not warn if
the #defines generated so far are ignored.

You replied:
> It has *wrong* quoting rules.  This has bitten people lots before.

The manual says that
   AC_TRY_COMPILE (INCLUDES, FUNCTION-BODY, ACTION-IF-TRUE, ACTION-IF-FALSE)
is the same as

          AC_COMPILE_IFELSE(
            [AC_LANG_PROGRAM([[INCLUDES]],
               [[FUNCTION-BODY]])],
            [ACTION-IF-TRUE],
            [ACTION-IF-FALSE])

Can I rely on that? If yes, then it's what I need.

When I write a piece of C code (INCLUDES or FUNCTION-BODY), in 99% of the cases
I want brackets to denote array dimensions or array indices. I don't want them
to expand to nothing.

You say that AC_TRY_COMPILE has the wrong quoting rules. But I am using the
macro for 15 years, and as a user I assert you that it has the right quoting
rules that I want.

> Please use AC_COMPILE_IFELSE.  There is a FAQ entry on this,
>   info Autoconf 'AC_FOO_IFELSE vs AC_TRY_FOO'

This FAQ says:

   - a more consistent interface: `AC_TRY_COMPILE' etc. were double
     quoting their arguments;

As a user, I want the quoting rules of AC_TRY_COMPILE. I don't want array
expressions to expand into nonsense by default. And I want the ability to
copy&paste code snippets from a .m4 file to a .c file and back.

   - the combinatoric explosion is solved by decomposing on the one
     hand the generation of sources, and on the other hand executing
     the program;

While I agree that this is theoretically elegant, as a user, I prefer to use
macros without practical pitfalls that hurt me every second time I use them.

   - this scheme helps supporting more languages than plain C and C++.

This is irrelevant for me. I don't use Fortran, and Java has enough reflection
facilities built-in that nearly eliminate the need for configure-time tests.

Bruno