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