Re: testing consistency

[Jim Wilson <wilson at cygnus dot com>]

My initial concern here is that there were mistakes in the arguments.
People were claiming that H.J.'s patch was changing behaviour, when in
fact it was restoring behaviour that was lost when we added the toplevel
directory.  If we choose not to accept H.J.'s patch, then we are deciding
to change how gcc operates.

Now that there has been so much discussion of it, we may as well revisit
whether the old behaviour was correct.

	HP is shipping me a _binary_.
	That's very different from someone picking up egcs/gcc source on the
	net and _building_ it.  

Yes.  I agree that this this a good argument against it.  Also, the arguments
about how installing into /usr will wreak havoc with people who have done
package installs.

Another argument which I am not sure if anyone has made yet is that changing
the toplevel configure will affect more packages than just gcc.  Checking
libio/libstdc++, I see that they don't default to prefix=/usr, so we may
not want to force that to be true.  If we eventually try to share this
tree with other packages, like binutils and gdb, then we are also changing
them if we change the toplevel configure.

I will talk to H.J. Lu about this.

Incidentally, if we don't accept H.J.'s patch, then we need to fix the
gcc/configure.in file to avoid conflicts over the default value of prefix.
There was a bug report posted within the last week of someone who got a
non-functional gcc because they made the mistake of configuring in the gcc
directory (defaulting to prefix=/usr) and then installing from the toplevel
directory (defaulting to prefix=/usr/local), so gcc was installed some place
differently than it expected to be installed.

Jim