Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Michael Elizabeth Chastain <mec.gnu@mindspring.com>
Cc: Andrew Cagney <cagney@gnu.org>, gdb-patches@sources.redhat.com
Subject: Re: [RFA/testsuite/ada] Put testcase code in own directory
Date: Wed, 01 Dec 2004 03:20:00 -0000	[thread overview]
Message-ID: <20041201032021.GG1204@adacore.com> (raw)
In-Reply-To: <41939655.7070503@gnu.org>

Michael,

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

Thanks,
-- 
Joel

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


  reply	other threads:[~2004-12-01  3:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-08 21:16 Joel Brobecker
2004-11-11 16:43 ` Andrew Cagney
2004-12-01  3:20   ` Joel Brobecker [this message]
2004-12-01  4:54     ` Daniel Jacobowitz
2005-01-20 17:18 ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041201032021.GG1204@adacore.com \
    --to=brobecker@adacore.com \
    --cc=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=mec.gnu@mindspring.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox