This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ compatibility testing
- From: Phil Edwards <phil at jaj dot com>
- To: Janis Johnson <janis187 at us dot ibm dot com>
- Cc: bkoz at redhat dot com, gcc at gcc dot gnu dot org
- Date: Sat, 21 Sep 2002 14:36:54 -0400
- Subject: Re: C++ compatibility testing
- References: <20020920145854.A9233@us.ibm.com>
On Fri, Sep 20, 2002 at 02:58:54PM -0700, Janis Johnson wrote:
> Phil and Benjamin,
>
> I'm again looking into how to set up tests within the GCC testsuite to
> build two pieces of a C++ test using different versions of GCC and then
> linking them and running the test. Phil, you mentioned that you might
> try this (http://gcc.gnu.org/ml/gcc/2002-08/msg01259.html); please let
> me know if you're doing something similar.
Er, well, best laid plans...
http://gcc.gnu.org/ml/libstdc++/2002-09/msg00119.html
Still catching up on versioning work.
> If you've got a scheme for
> specifying a second compiler for the test tools to use, let me know what
> it is.
When you posted your script to do this, you wrote:
> They required either building
> object files with older compilers ahead of time and then using those
> archived files when testing the new compiler, or else having both old
> and new compilers available when running the tests.
I will be using the second approach, since I already have both compilers:
http://gcc.gnu.org/ml/gcc/2002-08/msg01133.html
For each night, I can just run the autocrasher, then I have both branches
available in an easily computable pathname:
27% ls -d build/*2002-09-21*
build/build-2002-09-21/ build/install-2002-09-21/
build/build-2002-09-21-3.2/ build/install-2002-09-21-3.2/
build/build-2002-09-21-trunk/ build/install-2002-09-21-trunk/
28%
So, using a variant of your script, OLDCXX is install-(the_date)-3.2/bin/g++
and NEWCXX is install-(the_date)-trunk/bin/g++.
I still have not thought of a decent way to do this inside the gcc testsuite.
It may be that we need to use the first approach for general testing,
and have some .o's sitting around for people.
> After I've got things working with building simple relocatable objects
> and linking them together, I'll try building the pieces of a test into
> static and/or shared libraries in the hopes of finding different kinds
> of problems. That might be messy using dejagnu, though, and I only have
> GNU/Linux systems on which to try out my changes.
You might (or might not) find it easier to use the QMTest thingy that
the Software Carpentry slash CodeSorcery folks are putting together.
I made one pass, but apparently my version of Python was too recent.
At any rate, making "unusual" configurations work is supposed to be much
easier in QMTest than in DejaGNU.
Phil
--
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
- Edsger Dijkstra, 1930-2002