Re: Testsuite question

[mrs at wrs dot com (Mike Stump)]

> Date: Tue, 13 Oct 1998 17:33:20 +0200
> From: Marc Espie <Marc.Espie@liafa.jussieu.fr>
> To: Mike Stump <mrs@wrs.com>

> On Mon, Oct 12, 1998 at 02:32:48PM -0700, Mike Stump wrote:
> > > Date: Sun, 11 Oct 1998 13:49:52 +0200
> > > From: Marc Espie <espie@quatramaran.ens.fr>
> > > To: egcs@cygnus.com
> > 
> > > Is it possible to include test files in the suite that involve compiling
> > > AND linking...
> > 
> > Yes, but it requires some work.  First, a design, then an
> > implementation, then you just add the testcases.  I can give you, or
> > help with the design, but don't have enough time for the
> > implementation.

> Some pointers with the design might help... as long as I get some
> help so that I don't botch the design hopelessly, I can probably
> handle the rest...

I recopy this back to egcs, so that others may comment on my comments,
and so that there is a log of it if you don't submit the work.

If we have a testsuite driver (like old-deja.exp, or an extention of
old-deja.exp that looks for files of the form base-[0-9]+.C, and
compiles up each one, and then links the group together, convention
would be to have link flags in the name-1.C file, and each .C file
would have its own compile options.  // ERROR wouldn't make sense to
have in those files.  The compilation of each file would be a
testcase, the final link would be another, and if it is to be run
(follow the existing logic on when to run), yet one more.

`Special ld Options: ' can be the new key for link options, if any.
See existing code on how to pull them out.

Best to just put your changes into the two old-deja.exp files
(testsuite/lib and testsuite/g++.old-deja/ as appropriate and make
them conditional on a global variable and then in
g++.multipart/old-deja.exp put a set of that variable and just include
../g++.old-deja/old-deja.exp.  I think this will work.  If you find a
better way to do it, that's fine too.  Please just don't copy 1000
lines of tcl code, please.

To find testcases, instead of looking for *.C, look for *-1.C, and
then within that testcase, you can find basename-*.C for the complete
set of source files.

What have I missed?  Hum...  I think that will allow us to have -frepo
tests, missing vtable tests, multiple defs tests, undef tests,
external/static tests and so on.  Are there any last styles of tests
that aren't covered that could be with a mod to the general scheme as
above?

If any thing was unclear or if you find yourself needed more detail,
just ask.  I kept it kinda simple and high level.  Wait a couple of
days and and see if anybody adds to or flames my design.  I think it
should be reasonable.

If you find the time to help us improve the test harness, thanks.