%% Ossama Othman <[EMAIL PROTECTED]> writes:
oo> Before you read on, I'd just like to point that I do agree with your
oo> "(c)" alternative. So please keep that in mind when you read my
oo> disagreements below. I really don't want to get into a "heated"
oo> debate. :-)
S'ok :).
oo> 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_.
oo> Sorry. I disagree with your assessment.
It seems to me that we agree on almost every point--except the
conclusion! :). I wonder if you can help me understand your objection
to changing the default behavior of autoconf (again, I'm not suggesting
we remove any functionality, only that we change the default behavior).
Maybe simpler would be for others to describe what they feel is the
right behavior.
oo> While I agree that such a configuration is most likely incorrect,
oo> I do not believe that it should be "absolutely" incorrect. Again,
oo> I admit that I can't think of any reason why anyone would want
oo> such a configuration, but IMHO autoconf should not be so
oo> restrictive.
That's why I said, "absolutely incorrect _by default_". In other words,
autoconf should assume that configurations which are almost certainly
bogus, _are_ in fact bogus, unless the user (or possibly the
configure.in creator) says otherwise.
oo> However, this point is moot since the proposed Autoconf patch
oo> prevents "mismatched" configurations from being used. Is this
oo> correct?
Yes, but it prevents them in a way that makes it _MORE_ likely that you
will get the wrong behavior, instead of _LESS_ likely (IIUC).
>> I would also say that _any_ detected cross-compiler is "very suspicious"
>> _by default_, and configure should die immediately.
oo> If all you work with is cross-compilers, then wouldn't this annoy you
oo> to no end? Embedded software developers do a great deal of their work
oo> with cross-compilers.
I, in fact, do almost all my real work on embedded software with
cross-compilers :). Unfortunately my work environment is
_significantly_ less pleasant to work with than autoconf :-/.
I don't believe this is an issue. The people doing this kind of work
with autoconf are (a) an extremely small minority, and (b) quite
obviously technically savvy enough to take this change in stride.
>> I think that the person writing configure.in is the best one to know
>> what the expected and legal situations are.
oo> Exactly! So why should autoconf make any of the decisions you say it
oo> should?
Autoconf is _ALREADY_ making decisions. It's trying to autodetect a
cross-compilation environment. The problem is, it's impossible to
_correctly_ autodetect that, and right now it's getting it wrong _far_
more often than it gets it right.
I'm essentially saying, turn off (by default) cross-compiler
autodetection in autoconf. Don't let autoconf make these guesses, when
it's almost always guessing wrong. It doesn't work. Force people who
really want cross-compiling to specify that, or allow configure.in
maintainers to specify when cross-compiling is reasonable.
oo> The configure.in developer should not be limited by autoconf (to
oo> some extent), no matter how odd the configuration appears to be.
I've never said or implied they would be. Maybe I didn't make my
suggestions clear enough.
I'm saying change the default behavior, I'm not saying remove any
features. Just turn them off by default.
>> 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.
oo> What if your default compiler really is a cross-compiler?
Then you go with (b). Note I'm saying _all_ of these are implemented,
not just one of them. Maybe that's the source of the confusion.
You could add the option in (b) to the site config file, if you like, if
you do this kind of thing more often than not.
>> 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.
oo> *sigh* :-)
oo> I just don't see why enabling cross compilation is "adventerous"
oo> or "foolish," especially if that is what you want. Presumably
oo> anyone who enables cross compilation knows what they are doing.
oo> Autoconf should not get in their way.
I didn't say it should...? That's why I suggested a user option in the
first place. If you want it, you can get it.
All I'm saying is, force the user to specify the option. Don't try to
guess whether he wanted it or not, since that can't be determined with
anything approaching accuracy.
My comments about "adventurous" and "foolish" were meant to be applied
to people trying to cross-compile packages that the maintainer
him/herself didn't certify as being cross-compilable, not to packages
where cross-compilation is expected and catered to.
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
