From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2606 invoked by alias); 6 Dec 2001 02:00:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 2544 invoked from network); 6 Dec 2001 02:00:12 -0000 Received: from unknown (HELO prserv.net) (32.97.166.34) by sources.redhat.com with SMTP; 6 Dec 2001 02:00:12 -0000 Received: from JVDSYS (slip139-92-166-249.ehv.nl.prserv.net[139.92.166.249]) by prserv.net (out4) with ESMTP id <2001120602000820404h80n0e>; Thu, 6 Dec 2001 02:00:10 +0000 X-Mailer: emacs 21.1.1 (via feedmail 8 I); VM 6.71 under Emacs 21.1.1 From: "Jerry van Dijk" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15374.53533.850000.197373@gargle.gargle.HOWL> Date: Wed, 05 Dec 2001 18:00:00 -0000 To: guerby@acm.org Cc: gcc@gcc.gnu.org Subject: Re: ACATS legal status cleared by FSF In-Reply-To: <200112052305.fB5N5D700531@ulmo.localdomain> References: <200112052305.fB5N5D700531@ulmo.localdomain> Reply-To: jvandyk@attglobal.net X-SW-Source: 2001-12/txt/msg00258.txt.bz2 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