Re: [PATCH] A better (?) _AC_EXEEXT

[Morten Eriksen]

* 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.

* Akim
| The previous code was, apparently, able to cope with other
| extensions than `' and `.exe'.

The previous code was completely fubar and a butt-ugly joke. There's
no chance in hell it would have coped with any platform where the
executable suffix was anything but blank. Oh, and it could cope with
.exe on exactly three specific platforms -- through the hack of naming
those three platforms explicitly.

| I know of no others, agreed, but we could keep this part.  I
| wouldn't struggle though :)

The new _AC_EXEEXT could easily be extended to try out any other
executable suffix, if any platform was discovered where it would serve
a purpose.

* Morten
| BTW, is the "-ef" option to ``test'' portable? If not, that part could
| be stripped out.

* Akim
| [no]

Ok, I'll rewrite that part then, and re-submit with a new patch
tomorrow.

* Morten
| AFAICS, this should also kill the last trace of use of _AC_CYGWIN,
| _AC_MINGW32 and _AC_EMXOS2.

* Akim
| This is good and bad.  I'm in favor of removing these macros,
| because people should then depend upon AC_CANONICAL_HOST.  But if
| some people think we should keep them, then we should reimplement
| then on top of the AC_CANONICAL macros.

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?

I'll submit a patch for this too. I assume those macros should be
marked "obsolete" aswell? I haven't really looked at the Autoconf
mechanisms to do this, so I might need a helping hand to complete the
patch.

Regards,
Morten