public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Jerry van Dijk" <jvandyk@attglobal.net>
To: guerby@acm.org
Cc: gcc@gcc.gnu.org
Subject: Re: ACATS legal status cleared by FSF
Date: Wed, 05 Dec 2001 18:00:00 -0000	[thread overview]
Message-ID: <15374.53533.850000.197373@gargle.gargle.HOWL> (raw)
In-Reply-To: <200112052305.fB5N5D700531@ulmo.localdomain>


guerby@acm.org writes:

 > To avoid preprocessing and script-like machinery overhead, I propose
 > that we commit the ACATS sources directly in the form expected by
 > GNAT, so we end up just having a list of main unit names, and so a
 > simple minded loop of "gnatmake x; run x" will be the only thing
 > needed to run. 
 > 
 > [1] Any objection?

I assume we want to run an ACATS subset as a basic sanity check, right ?
But even in that case, it would be advisable to follow the changes made
to the test suite. Your proposal means this has to be done manually by
someone. Who is going to monitor this, and propagate all changes in the
tests ?

 > [2] Do we want to keep some subdirectories, if so what granularity, or
 > all in one dir is okay (something like 4000 files)?

I like the current subdirectory structure, it makes it easier if you want
to check just one test, or a set or related tests.

 > [5] IMHO it is best if the form in which we commit the sources of the
 > ACATS tests is as separated as possible from the testsuite harness
 > technology at first, just sources, README and a list of test names.
 > Okay?

I would a a minium also add the scripts to run all test automatically
and report on them. Also a way to run a single test for debugging.

 > The B tests require a lot of maintainance (hundreds of pages of
 > changes each time you improve a message, split of files with too many
 > errors, etc...), and have no value for the backend, may be someone
 > will volunteer the packaging, but not me. I assume ACT dedicates
 > someone to this task anyway :).

I think it's important to test the whole GNAT system, not just the backend.
The value of the B tests is that it alerts you to unexpected changes. I think
that at least for now they should stay. We can add 'skip tests' for changes
that are to much work for the added value.

 > [12] Do we want to scrap the legalese and replace it by something else?
 > Do we want to identify changes or extension made within the GCC
 > project, and if so how?

I do not think you are allowed to 'scap the legales'.

Basically the question is if you want to see the test suite as an scaled
down ACATS (in which case all changes etc need to be documented), or see
ACATS as a starting point, and develop the suite further, for example
adding regression testing for discovered bugs, etc.

My first impulse is to stick to ACATS, to follow language development,
and add extra tests separately.

Just my opinion, of course.

-- 
--  Jerry van Dijk   | email: jvandyk@attglobal.net
--  Leiden, Holland  | web:   home.trouwweb.nl/Jerry

  parent reply	other threads:[~2001-12-06  2:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-05 15:13 guerby
2001-12-05 16:21 ` Joseph S. Myers
2001-12-05 18:00 ` Jerry van Dijk [this message]
2001-12-06  3:36 ` Geoff Keating
2001-12-06  9:34 ` Geert Bosch
2001-12-06 11:48   ` Zack Weinberg
2001-12-06 14:24     ` Geert Bosch
2001-12-06 14:32       ` Joseph S. Myers
2001-12-06 15:10       ` Zack Weinberg
2001-12-06 15:41         ` Geert Bosch
2001-12-06 18:22           ` Zack Weinberg
2001-12-05 15:28 Richard Kenner
2001-12-05 15:41 ` guerby
2001-12-05 23:36 dewar
2001-12-06 15:01 Richard Kenner
2001-12-06 15:40 Richard Kenner
2001-12-06 17:38 dewar
2001-12-06 19:09 dewar
2001-12-07  3:18 Richard Kenner
2001-12-07 17:59 dewar
2001-12-07 18:50 mike stump
2001-12-07 18:57 dewar
2001-12-07 19:12 dewar
2001-12-09 13:02 ` Zack Weinberg
2001-12-09 14:52   ` guerby
2001-12-09 19:47     ` Geert Bosch
2001-12-09 14:00 dewar
2001-12-09 15:06 dewar
2001-12-09 15:55 ` Joseph S. Myers
2001-12-09 19:03 dewar

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=15374.53533.850000.197373@gargle.gargle.HOWL \
    --to=jvandyk@attglobal.net \
    --cc=gcc@gcc.gnu.org \
    --cc=guerby@acm.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).