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')?
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.
If configure can't build a binary that will work reliably _to
the
best of our knowledge_ then it should stop. If we want to offer the
user a --use-broken-compiler option then that's fine--- how else
will the problems get debugged. But using a known broken compiler
should not be a default action.
I think we should use the compiler the user specified. If we think
there is a problem with that, bitch and moan -- but don't bomb out.
> Warnings would be fine, though.
configure spews a long series of messages. A warning will be lost
in all that.
I think the warnings at the end are nicely visible.
I build XEmacs like this
./configure; make
and then go do something else while it grinds. If we expect people
to pay attention to the warnings, either configure has to generate
much less output or configure has to abort, so that the user is
forced to read the message and take some action.
Most users separate the `configure' and `make' steps, I hope. Also,
non-beta XEmacsen spew much less configure output.