Re: egcs testsuite & dejagnu : A special case?

[mrs at wrs dot com (Mike Stump)]

> Date: Tue, 30 Jun 1998 09:44:28 -0400 (EDT)
> From: Craig Burley <burley@gnu.org>

> >dejagnu however is not exactly a model of cleanliness.

> This reminds me of a thought I had the other day while not on-line.

> I've gotten the impression (not knowing much about how all this
> testing stuff actually works at this point) that some of the
> problems we've run into are due to attempting to be able to test an
> *uninstalled* compiler as well as an installed one.  Is that true?

:-)  Craig, what a question!  There's not enough information for me to
tell...

For C++ there is a way to run the compiler out of the build tree such
that is is almost indistinguishable from an installed compiler.  For
testing purposes, it is usually indistinguishable.

dejagnu has some of the logic and the Makefiles have some of the
logic.

gcc also runs fairly well I think.

> Certainly it's often the case that I want to run tests of my own
> (using my own primitive test suite, or just try out a submitted test
> case or something), and I've done a variety of things over the years
> to cope with the fact that I want to try out a *built*, but not
> *installed*, version of the compiler.

For a maintainer, this is critical.  I do something like (when last I
did this):

#!/bin/sh
case "$HOSTTYPE" in
    sparc) arch=sol
	;;
    hp9000s700) arch=hppa
	;;
    sgi) arch=sgi
	;;
    alpha) arch=alpha
	;;
    RISC6000) arch=rs6000
	;;
esac

#arch=sol
#arch=tic80
#arch=sun4
#arch=sgi
#arch=alpha
#arch=rs6000
#arch=alpha-dec-osf2.0
#arch=hppa

#arch=i586-unknown-linux
#arch=i586

srcdir=${HOME}/egcs
objdir=${HOME}/$arch

LIBS=
echo " $* " | grep " -[cSE] " >/dev/null
if [ $? = 1 ]; then LIBS="-lstdc++"
fi
exec ${objdir}/gcc/xgcc -B${objdir}/gcc/ ${1+"$@"} -I${objdir}/libio -I${srcdir}/libg++/src -I${srcdir}/libio -I${srcdir}/libstdc++ -I${srcdir}/libstdc++/stl -I${objdir}/gcc/include -L${objdir}/libg++ -L${objdir}/libstdc++ $LIBS

Not pretty, but it is close.

> (On my old 486/33, I had a bunch of shells scripts installed in
> /usr/local/bin that'd invoke the compiler in canonical places in my
> home directory, using the appropriate -B and -L switches, etc.  Now
> that I have a much faster system, I just specify a unique --prefix
> and do "make install" each time it seems appropriate, which takes
> only about a minute, but not everybody has that.  And, I admit it's
> tedious to keeping typing full pathnames like
> `/develop/g77/0.5.23/bin/g77' to specify which version of the
> compiler I want to run.  That's a minor problem compared to back
> when I couldn't really maintain more than two versions, though!)

I install a full tree every now and then, but for the day to day
stuff, I only ever use the build directory.  Also, you can get around
names by having sym links from things like ../local/bin/gcc272 to
../local/gcc-2.7.2.3/bin/gcc have only have local/bin in your path.

Further, I usually g++ -E to get a .ii file, and then I can feed that
stright to cc1plus by hand.  I then just look at the .s file and go
from there.

> It occurred to me that, maybe, we could avoid much of this trouble
> by, instead of working around the differences between installed and
> uninstalled compilers *externally* (to the compiler itself, that
> is), we could define a new interface to the compiler *itself* that,
> when invoked, amounts to saying "I'm invoking the *uninstalled*
> compiler", and leave all the mucking about with pathnames and such
> to the new interface.

A way I like better is to have an etc/{g77,gcc,g++} in the build tree
that invokes out of the build tree, and if you want it, you just use
it.

> For example, what if we had the build process automatically build,
> but not install (obviously), shell scripts

Yes.

> Does this idea have any merit?

Yes.

> Offhand it seems fairly simple to implement, and, once we change the
> pertinent tools (egcs top-level Makefile such as when doing `make
> check') to use them, could really reduce the maintenance headaches
> we seem to be having with trying to do useful work on uninstalled
> compilers.

I din't have any headaches because this is what I already do.  :-)