[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] A better (?) _AC_EXEEXT
From: |
Akim Demaille |
Subject: |
Re: [PATCH] A better (?) _AC_EXEEXT |
Date: |
11 Oct 2000 11:58:33 +0200 |
User-agent: |
Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) |
| * 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
- [PATCH] A better (?) _AC_EXEEXT, Morten Eriksen, 2000/10/10
- Re: [PATCH] A better (?) _AC_EXEEXT, Akim Demaille, 2000/10/10
- Re: [PATCH] A better (?) _AC_EXEEXT, Morten Eriksen, 2000/10/10
- [PATCH] A better _AC_EXEEXT, Take II, Morten Eriksen, 2000/10/11
- Re: [PATCH] A better (?) _AC_EXEEXT,
Akim Demaille <=
- Re: [PATCH] A better (?) _AC_EXEEXT, Morten Eriksen, 2000/10/11
- Re: [PATCH] A better (?) _AC_EXEEXT, Akim Demaille, 2000/10/11
- Re: [PATCH] A better (?) _AC_EXEEXT, Morten Eriksen, 2000/10/11
- Re: [PATCH] A better (?) _AC_EXEEXT, Akim Demaille, 2000/10/11
- Re: [PATCH] A better (?) _AC_EXEEXT, Morten Eriksen, 2000/10/11
- Re: [PATCH] A better (?) _AC_EXEEXT, Pavel Roskin, 2000/10/11
- Re: [PATCH] A better (?) _AC_EXEEXT, Akim Demaille, 2000/10/11
- Re: [PATCH] A better (?) _AC_EXEEXT, Pavel Roskin, 2000/10/11
- Re: [PATCH] A better (?) _AC_EXEEXT, Morten Eriksen, 2000/10/12
- Re: [PATCH] A better (?) _AC_EXEEXT, Pavel Roskin, 2000/10/12