* 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

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.


Bug-libtool mailing list

Reply via email to