As best as I can tell from the patches themselves (without applying and
running them), they don't address my issues--at least the solution is
not what I'd hoped for.
First, IMO warnings aren't good enough. Many people just run
"./configure && make" and go to lunch. They'll never see the warning as
it flips by on the screen (these tests are always done early, so they
scroll by fast and are long gone by the end). Another large percentage,
esp. the unsophisticated user who will have the most trouble with this,
will simply ignore the warning, even if they do see it, since "it's only
a warning".
Second, AFAICT this change makes it all or nothing, but the "all" will
always be cross-compilation. IOW, if _any_ compiler can't create a
runnable executable, all compilers are assumed to be cross-compiling.
To me, that's even worse than what we had before.
About all this buys us IMHO is a little more leverage to beat the poor
user over the head with after they contact us about problems ("well,
didn't you see the warning?"). That's not really what I'm interested
in, when configure can tell them right up front what their problem is.
I'd guess that 90+% of autoconf'd packages simply can't be
cross-compiled, and I know erroneous autodetection of cross-compilers is
the cause of at least half of the problem reports for the autoconf'd
packages I'm familiar with--_especially_ those that need a C++ compiler,
but even for regular C compilers like GCC which are misinstalled
somehow.
I think the default behavior of autoconf should be to reject _all_
very suspicious configurations, immediately and with prejudice.
"Very suspicious" to me absolutely includes mismatched cross
vs. non-cross compilers. Configure should spit teeth and die right
away in that situation, _by default_.
I would also say that _any_ detected cross-compiler is "very suspicious"
_by default_, and configure should die immediately.
I think that the person writing configure.in is the best one to know
what the expected and legal situations are.
This is what I would consider the best solution:
a) By default, all instances where a simple program can't be run after
linking successfully are treated as immediate, fatal errors, and a
message indicating "your compiler is broken" is printed.
b) There is a command-line option which will force the configure script
to allow cross-compilation. Maybe that option is --host (I wonder
if it should be something more explicit, like --enable-cross-compile
or something). This allows the user to override the behavior in
(a), for those adventurous or foolish enough to try it.
c) There is a flag package writers can give in configure.in which will
disable the check in (a), for those who are writing packages which
_do_ routinely expect to be cross-compiled (like GCC, etc.)
An alternative is to go the opposite way, and by default have behavior
(c) but allow a flag in configure.in to enable behavior (a) for those
writing packages which don't want to bother with cross-compilation.
Given the demographics I described above, I prefer the original method.
Appropriate additions to the default INSTALL file, etc. should be made,
of course. Maybe even a section describing common ways a compiler can
be misinstalled on various systems could be provided.
Anyone who is sophisticated enough to want to cross-compile is certainly
capable of reading the docs, and deserves to be thrashed with the
proverbial wet noodle if they don't do so.
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://www.ultranet.com/~pauld/gmake/
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
