Re: autoconf will accept a nonexistent compiler as the second one checked

[Ralf Wildenhues]

Hi Stepan,

* Stepan Kasal wrote on Sun, Apr 02, 2006 at 12:04:28AM CEST:
> On Mon, Mar 20, 2006 at 05:02:52PM +0100, Ralf Wildenhues wrote:
> > * Martin Michlmayr wrote on Mon, Mar 20, 2006 at 02:15:34PM CET:
> > > Well, I think in this case some more sanity checks are justified
> 
> yes, you are right, we should do the check ``whether FOO compiler works''
> again for each language.

Again, I agree with that notion.

> I prepared the following patch.  (Be sure to update your CVS checkout
> before applying it.)

I also think the patch does what it intends to do (except the naming of
the macros is a bit suboptimal now) .  I also agree that what it's
currently doing is not great, nor too desirable.  But I see two points
not to apply this patch now.

First, it breaks if used in conjunction with Libtool-1.5.22.  That is
due to the known Libtool bug that it unconditionally expands both
AC_PROG_CXX and AC_PROG_F77 even if the configure.ac script does not
otherwise mention C++ or Fortran 77.  (So, users would then have to have
compilers for these languages installed, even if the package won't
actually need them.)

I know that this is a hand-waving argument.  Making such a change as
proposed 6 months before a release would certainly invalidate it.  But
making it on short notice, effectively leaving out Libtool users until a
fixed Libtool version is released, and thus cutting yourself of of some
user base that could help testing is not the best I can imagine.  And
yes, I know we Libtoolers are really at fault here; all I ask is to
consider delaying this.

Second, I think any macro which unconditionally errors out is broken.
This keeps popping up again and again; see this thread, for example:
http://lists.gnu.org/archive/html/libtool/2006-03/msg00059.html
The key here is: you simply can't know all ways your users will be able
to make use of your macro; so strive to make it as generally useful as
possible; if you believe it must have a hard failure mode, then at least
make it overridable by an optional IF-FAILS argument.


FWIW, besides the real fix, CVS Libtool still pushdefs AC_MSG_ERROR to
work around AC_PROG_F77 failure: we want the Libtool package to compile
with Fortran support, if a Fortran compiler is available, but without
otherwise.

Cheers,
Ralf

> 2006-04-01  Stepan Kasal  <address@hidden>
> 
>       * lib/autoconf/c.m4 (AC_PROG_CC, AC_PROG_CXX, AC_PROG_OBJC): Call
>         _AC_COMPILER_EXEEXT instead of m4_expand_once([_AC_COMPILER_EXEEXT])
>       * lib/autoconf/fortran.m4 (_AC_PROG_FC): Likewise.
>       * lib/autoconf/lang.m4 (_AC_COMPILER_EXEEXT_TESTS): On subsequent
>         calls, for a new language, only check that the compiler works.
>       (AC_NO_EXECUTABLES): Change the redefinition of
>         _AC_COMPILER_EXEEXT_TESTS so that on subsequent calls, it checks
>         that the new language's compiler works if ac_no_link=no, and
>         does nothing otherwise.