Hi Paul,
On Fri, Feb 25, 2000 at 06:02:50PM -0500, Paul D. Smith wrote:
> As a package maintainer this is the most common configure-related
> problem _I_ see.
>
> Two things:
>
> 1) Cross-compilation should be turned off unless some autoconf macro
> exists that says "this package is cross-compiler capable". If the
> compiler can't run the compiler test program and this special macro
> isn't present, configuration should fail right there.
>
> Or, alternatively, there could be a command-line option which
> enables cross-compilation checking. The error above could be
> something like "Couldn't find a working compiler (if you want to
> cross-compile, add --enable-cross-compilation to the configure
> command)" or whatever.
This sounds reasonable.
> 2) If you've already tested for C and that decided it _wasn't_
> cross-compiling, then you test for C++ and it decides you _are_
> cross-compiling, that should be a fatal error right there, too.
I disagree. I don't think autoconf should impose any such
restriction. Admittedly, I can't think of any package that would
actually depend on a native C compiler and a cross C++ compiler.
Nevertheless, I think it is a bad idea to make autoconf assume that
such a situation is a fatal error.
Wouldn't your first suggestion take care of the second situation you
mention? If cross-compilation isn't enabled than the fact that both
compilers weren't native could be interpreted as a fatal error.
Explicitly enabling cross-compilation would perhaps convert that fatal
error into some noticeable warning created by AC_MSG_WARN, for
example, instead stopping the configure script.
I'd prefer to see something like this rather than impose the
restriction you describe. Thoughts?
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
