Hi Paul,
Before you read on, I'd just like to point that I do agree with your
"(c)" alternative. So please keep that in mind when you read my
disagreements below. I really don't want to get into a "heated"
debate. :-)
On Tue, May 16, 2000 at 03:10:22PM -0400, Paul D. Smith wrote:
> "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_.
Sorry. I disagree with your assessment. While I agree that such a
configuration is most likely incorrect, I do not believe that it
should be "absolutely" incorrect. Again, I admit that I can't think
of any reason why anyone would want such a configuration, but IMHO
autoconf should not be so restrictive.
However, this point is moot since the proposed Autoconf patch prevents
"mismatched" configurations from being used. Is this correct?
> I would also say that _any_ detected cross-compiler is "very suspicious"
> _by default_, and configure should die immediately.
If all you work with is cross-compilers, then wouldn't this annoy you
to no end? Embedded software developers do a great deal of their work
with cross-compilers.
> I think that the person writing configure.in is the best one to know
> what the expected and legal situations are.
Exactly! So why should autoconf make any of the decisions you say it
should? The configure.in developer should not be limited by autoconf
(to some extent), no matter how odd the configuration appears to be.
BTW, Akim I'm not saying that the patch should be changed. I'm
perfectly happy with your suggested patch. I'm merely stating an
opinion. :-)
> 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.
What if your default compiler really is a cross-compiler?
> 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.
*sigh* :-)
I just don't see why enabling cross compilation is "adventerous" or
"foolish," especially if that is what you want. Presumably anyone who
enables cross compilation knows what they are doing. Autoconf should
not get in their way.
> 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.)
I like this idea.
> 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.
I agree with you here, too. The number of native compiler users
surely must far surpass the number of cross-compiler users.
> 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.
Right.
> 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.
Hehe, yes indeed. :-)
-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
