* Peter O'Gorman wrote on Thu, Mar 06, 2008 at 08:57:56PM CET:
> Ralf Wildenhues wrote:
> >
> > I'm considering doing that (the stop-gap measure).
>
> Your call.
I've applied that now.
> > Yes, and I can conceive just as well a libtool-using package which may
> > optionally use a Java compiler, and thus its configure script should not
> > bail out at Libtool's whim either.
>
> I agree, the way LT_LANG has worked so far is to test if a compiler for
> the language exists and is executable (or something similar), but not
> cause an error if it does not.
>
> What would be ideal is to check that the compiler exists, is executable,
> works (an possibly, when not cross-compiling, test that trivial code
> that is compiled with the compiler runs) but not cause an error if the
> compiler is broken or does not exist, simply warn the user that a broken
> compiler was detected and set the same vars in the same way as would be
> set if no compiler was detected.
Actually I would have liked it if
AC_PROG_{CC,CXX,F77,FC} and AM_PROG_GCJ
did the functionality testing, _and_ had an optional IF-FAILS argument,
defaulted to AC_MSG_ERROR. That allows flexibility but has the right
default. I think that would be enough, too: LT_LANG then would not have
to check for functional compiler.
Unfortunately, such an interface will break compatibility.
Cheers,
Ralf
_______________________________________________
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
