[RFA/testsuite/ada] Put testcase code in own directory

Joel Brobecker brobecker@adacore.com
Wed Dec 1 03:20:00 GMT 2004


> nothing for or against this.  However it's strategic decision - one for 
> MichaelC - should for package like languages such as ada (and for that 
> matter java) we have a directory per test? :-)

In reviewing this patch, I see that there are some pieces that I forgot
to include. So the patch can not be accepted as is.

However, would you mind telling us what you think about the principle?
If you want my opinion, I am strongly attached to the idea of having
one subdirectory per testcase. The current approach used for C where
you can pretty much always have all the code for one testcase stored
in one .c file simply does not work for Ada. With GNAT, you need the
filename to match the name of the unit, and you need to have one and
only one unit per file[1]. Most testcases will involve at least 3 files,
one containing the main procedure (that one compilation unit), plus
a .ads file containing the spec of a package, plus a .adb file
containing the body of a package. Some testcases will use many
more files than this (we have one testcase internally that creates
something like 200 packages).

For maintenance reasons, I really feel that one subdirectory per
testcase is the way to go.

I hope you'll agree with me, in which case I'll work on producing
a new iteration of this patch, complete this time.

> >2004-11-08  Joel Brobecker  <brobecker@gnat.com>
> >
> >        * gdb.ada/gnat_ada.gpr: New file.
> >        * gdb.ada/gnat_ada.gin: Delete, no longer used.
> >        * lib/ada.exp (gdb_compile_ada): Minor adaptation to new project 
> >        file.
> >        * configure.in: No longer generate gnat_ada.gpr.
> >        * gdb.ada/Makefile.in: Minor adaptation due to new project file.
> >        * gdb.ada/null_record.exp (testfile): executable is now in
> >        null_record subdirectory.
> >        (srcfile): Use full path to the main compilation unit.
> >
> >Tested on x86-linux.


[1]: This rule can actually be worked around with GNAT, by using
     gnatchop. What you do then is storing all the code in one file,
     and then let gnatchop parse it and cut it into files that follow
     the GNAT convention. I don't like this approach, though. One of
     the problems is that it is suboptimal in terms of efficiency, since
     you end up parsing the entire code to split it every time you run
     the testcase. It's just better to have then already splitted. It's
     also easier to track the changes in individual files rather than
     one bigger file. And also, we might override during the split other
     files created during previous testcase runs. Very annoying to have
     the wrong code when you come back after en entire testsuite run and
     try to understand why a given test failed.

More information about the Gdb-patches mailing list