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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
