Re: PR4114, 4113, 4082, 4078, (part of) 4096 plus other reports in gcc-bugs

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <Pine.SOL.3.91.1010824150430.7425B-100000@taarna.cygnus.com>,
Benjamin Kosnik <bkoz@redhat.com> writes:

>> The question is: How do we clean this mess up?  At this point, I don't
>> even see what is wrong with include/Makefile.am .

> Hmm. I think we can either make in-source builds work, or not. If we 
> can't, then configure should bomb out: this is what libjava did (does?)

I know that logically you are quite right.  I also know that the FSF
says it must work.

I have cloned my normal CVS tree and I have short-circuited the full
bootstrap with:

./configure
gmake configure-target-libstdc++-v3
cd i386-unknown-freebsd4.3/libstdc++-v3/include
gmake

At which point I see the error...

This seems WRONG (or is at least why everyone that configures this way
thinks an extra .. is required in the path when it is used):
glibcpp_srcdir = /usr/users/rittle/tmp/gcc-3.0/i386-unknown-freebsd4.3/libstdc++-v3

glibcpp_srcdir is /usr/users/rittle/tmp/gcc-3.0/libstdc++-v3
when srcdir != objdir.  Why on this green earth is a *srcdir*
variable different when configured off the same src tree?  Anyone?

However, from PR4096 and others, we know other subtle issues exist in
this case.  They existed before the latest patch entirely broke it.

> I suspect that an effort should be made to make in-source builds work. 

OK, then we should change our documented stance and ~50% of all gcc
developers should commit to configuring in-source that way by default
(not exactly what Neil does).  Otherwise, we will not find the cases
when we break it and all the work to fix it this one time is for
nought.  You and I both know that developers are not going to change
since it is dumb to work this way with a CVS working tree...

Regards,
Loren