Hi Paul,
On Tue, May 16, 2000 at 06:06:36PM -0400, Paul D. Smith wrote:
> %% 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 :).
Thanks. 8)
> 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).
Perhaps I misinterpreted what you said. I'll try to clarify things
below.
> Maybe simpler would be for others to describe what they feel is the
> right behavior.
Okay, I'll give it a shot.
I agree with your idea of providing the developer with the ability to
enable cross-compiler support (detection?), and that native compiler
detection should be the default since this is the common case.
My concern was that Autoconf could potentially make too many decisions
on the developers behalf without providing a means for the developer
to override this behavior. From what I understand now about what you
said, you proposed that some way of changing Autoconf's default
decision making behavior with respect to cross-compiler support,
including detection, be made available to the developer via some
configure.in macro/option and to the user via some command line
configure script option. Am I now interpreting you correctly? If not
please let me know. :-)
> 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.
Okay, I understand what you were saying now. I agree.
> 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 guess I need to run through the patch more closely since it appears
that I made too many assumptions about it.
> >> 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 :).
My sympathies. :-)
> Unfortunately my work environment is
> _significantly_ less pleasant to work with than autoconf :-/.
I can imagine.
> 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.
That is true. I guess was thinking of the few who would complain
without RTFM.
> >> 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.
Right. I'm sure that this issue has already been beaten to death, but
I haven't been a bit distracted these past few weeks. Have any steps
been taken to address the faults with the detection code, at least to
improve it, and despite the fact that is impossible to correctly
detect a cross-compiler?
> 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.
No, I probably misinterpreted them. Sorry.
> I'm saying change the default behavior, I'm not saying remove any
> features. Just turn them off by default.
Alrighty.
> 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.
Paul, I think that for the most part I agree with your suggestions.
Now on to Akim. :-)
-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
