Hrvoje Niksic writes:
Kyle Jones <kyle_jones(a)wonderworks.com> writes:
> Hrvoje Niksic writes:
> > Kyle Jones <kyle_jones(a)wonderworks.com> writes:
> >
> > > Why wait for XEmacs to crash? We should make configure flat out
> > > refuse to build XEmacs using egcs-1.1. After seeing people report
> > > the gcc-2.7 -fcaller-saves induced crash over and over again, I
> > > think we should refuse to build using broken compilers unless we
> > > have a fix in place.
> >
> > Well. Uhm. I think that's a bit too harsh. I don't like configure
> > bombing out on me unless there's a *really* good reason for that.
>
> This isn't a good reason?!
Can configure really know that the binary will come out corrupt? What
if I specify `--cflags=-g'? What if I specify `-O' (as opposed to
`-O2')?
That is what testing will hopefully tell us. Then we encode that
knowledge in configure and forget about it. configure was made
for tedium like this.
But I gather that no one really knows whether EGCS 1.1 is broken
or not. Has anyone looked at the compiler's assembler output?
Bombing out during configure is very harsh because, unlike
`make', there is no convenient way to fix the problem and
"resume" the configuration -- you have to start over. Bombing
in configure should be a last resort, not a standard practice.
There is no point in continuing if the binary you're going to
produce is hosed. If the binary doesn't work, you still have to
start over. The goal is to produce something the user can use and
rely on, yes? The compiler is one of the first things checked by
configure, so the user doesn't lose much time. On my slug-slow
486, I'd much prefer to get an error early than wait a hour for
XEmacs to build and then discover that the binary crashes.