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

[Benjamin Kosnik <bkoz at redhat dot com>]

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

Yeah. Well. 

> 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

Dunno.... this is set in acinclude.m4 (GLIBCPP_CONFIGURE)

glibcpp_builddir=`pwd`
case $srcdir in
[\\/$]* | ?:[\\/]*) glibcpp_srcdir=${srcdir} ;;
*) glibcpp_srcdir=`cd "$srcdir" && ${PWDCMD-pwd} || echo "$srcdir"` ;;
esac
AC_SUBST(glibcpp_builddir)
AC_SUBST(glibcpp_srcdir)

There's a long history of this crazy bit, which you may remember, where 
Richard Henderson, Rainer, etc. need this configure bit for their NFS source 
partition or whatever.

> 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...

Hmm. Well, we'll have to have some of each camp use amd, or whatever NFS 
automounter that also seems to be a perennial issue. And some should use 
gmake. Some should use new autotools...

... you get my point. It would be nice if the build process was bullet proof.

It's not.

I think that the configure/build process is complex and only getting more 
tricky. Configurations that are out of the usual are going to break, 
plain and simple.

What might be a better idea is to check, before libstdc++ releases, that 
builddir == srcdir works (or doesn't, and hard code a configure error), 
and that Gerald's pathological build directory (with colons and forward 
slashes, escape codes, whatever) works. 

That way we don't have to mess with it all the time, and when people 
insist on configuring this way, the maintainers can insist on using 
a stable version. Sound reasonable?

-benjamin

ps. as an aside, would it be possible for some of your BSD regression 
testers on x86/alpha to test the experimental tree? I would like to be 
able to keep tabs on this stuff, and gcc-testresults seems like a good 
way to do it. It's very helpful when I make config changes.