Re: [PATCH] A better (?) _AC_EXEEXT

[Akim Demaille]

| * Morten
| | It was also mentioned on the list a while ago (by yours truly) how the
| | _AC_EXEEXT macro has a circular dependency: _AC_EXEEXT uses
| | AC_LINK_IFELSE which uses $ac_exeext which is found by _AC_EXEEXT.
| 
| * Akim
| | AFAICS you still have this problem: you use AC_LINK_IFELSE.  You
| | shouldn't, rather, see how AC_OBJEXT uses AC_TRY_EVAL directly,
| | that's the way to go.
| 
| Nope -- and I should know, as I'm the one who rewrote AC_OBJEXT to use
| AC_TRY_EVAL. :^)
| 
| Anyway, that's exactly what I was trying to do with AC_EXEEXT too,
| until I stumbled into this: to find the suffix for an executable, we
| need to compile a sourcecode file into an executable, but to make an
| executable we need to know which name to give it.
| 
| Or to put it like this: what do you end up with if you use
| AC_TRY_EVAL(ac_link)? Here's the definition of ac_link for C:
| 
| ${CC-cc} -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext 
$LIBS >&AC_FD_LOG
| 
| See that "conftest$ac_exeext"? :^/  Ok, no problem I thought -- I'd
| just eval this instead:
| 
| ${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&AC_FD_LOG
| 
| ..but this would of course give us an executable named "a.out" with
| just about every UNIX compiler under the sun. And I don't think ".out"
| is the suffix we want to use on UNIX platforms..
| 
| So I actually think its pretty hard to find the "default executable
| suffix" on a platform without playing nasty tricks. That's why I've
| changed the semantics of _AC_EXEEXT to rather check for a valid suffix
| among an ordered list of prefered suffices we'd like to use.

Sorry, but I am still lost.  I was not referring to theoretical
dependencies, I'm referring, as a first step, to actual AC_REQUIRE
dependencies.  Your patch, as is, does not solve one of the most
important issues: since AC_PROG_CC launches AC_EXEEXT which uses
AC_LINK_IFELSE which requires AC_PROG_CC, autoconf should and will
fail.  This is the circular dependency I'm referring to.

AC_LINK_IFELSE must keep its AC_REQUIRE on AC_PROG_CC, hence you must
not use AC_LINK_IFELSE.  That's why I first suggested using
AC_TRY_EVAL: to avoid the AC_REQUIRE.

Note, too, that if you feel it is exactly AC_LINK_IFELSE that you
need, then you should change:

  # AC_LINK_IFELSE(PROGRAM, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
  # -----------------------------------------------------------------
  # Try to link PROGRAM.
  AC_DEFUN([AC_LINK_IFELSE],
  [AC_LANG_COMPILER_REQUIRE()dnl
  m4_ifvanl([$1], [AC_LANG_CONFTEST([$1])])dnl
  if AC_TRY_EVAL(ac_link) && test -s conftest$ac_exeext; then
    m4_default([$2], :)
  else
    echo "configure: failed program was:" >&AC_FD_LOG
    cat conftest.$ac_ext >&AC_FD_LOG
  m4_ifvanl([$3], [  $3])dnl
  fi
  rm -f conftest.$ac_objext conftest$ac_exeext ifval([$1],
                                                     [conftest.$ac_ext])[]dnl
  ])# AC_LINK_IFELSE

into

  # _AC_LINK_IFELSE(PROGRAM, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
  # ------------------------------------------------------------------
  # Try to link PROGRAM.
  define([_AC_LINK_IFELSE],
  [m4_ifvanl([$1], [AC_LANG_CONFTEST([$1])])dnl
  if AC_TRY_EVAL(ac_link) && test -s conftest$ac_exeext; then
    m4_default([$2], :)
  else
    echo "configure: failed program was:" >&AC_FD_LOG
    cat conftest.$ac_ext >&AC_FD_LOG
  m4_ifvanl([$3], [  $3])dnl
  fi
  rm -f conftest.$ac_objext conftest$ac_exeext ifval([$1],
                                                     [conftest.$ac_ext])[]dnl
  ])# _AC_LINK_IFELSE
  
  
  # AC_LINK_IFELSE(PROGRAM, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
  # -----------------------------------------------------------------
  # Try to link PROGRAM.
  AC_DEFUN([AC_LINK_IFELSE],
  [AC_LANG_COMPILER_REQUIRE()dnl
  _AC_LINK_IFELSE($@)])

and use _AC_LINK_IFELSE instead.  Likewise wrt AC_COMPILE_IFELSE.



| I've already rewritten _AC_CYGWIN to use AC_CANONICAL_something (where
| "something"="TARGET", I think). It was kinda hard to figure out the
| correct semantics of the macros, though -- what AC_CANONICAL_x should
| be used?

You may call AC_CANONICAL_TARGET (while AC_CANONICAL_HOST is more
logical), but you must depend on the *_host variables, *not* the
target vars.  See the doc for more details.

        Akim