Return-Path: 
 <stdcxx-dev-return-2949-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org
Received: (qmail 58575 invoked from network); 21 Mar 2007 16:49:30 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 21 Mar 2007 16:49:30 -0000
Received: (qmail 68180 invoked by uid 500); 21 Mar 2007 16:49:38 -0000
Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org
Received: (qmail 68166 invoked by uid 500); 21 Mar 2007 16:49:38 -0000
Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:stdcxx-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:stdcxx-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:stdcxx-dev@incubator.apache.org>
List-Id: <stdcxx-dev.incubator.apache.org>
Reply-To: stdcxx-dev@incubator.apache.org
Delivered-To: mailing list stdcxx-dev@incubator.apache.org
Received: (qmail 68151 invoked by uid 99); 21 Mar 2007 16:49:38 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Mar 2007 09:49:38 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: local policy)
Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Mar 2007 09:49:27 -0700
Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59])
	by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l2LGn0sR011551
	for <stdcxx-dev@incubator.apache.org>; Wed, 21 Mar 2007 16:49:02 GMT
Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with
 Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 21 Mar 2007 10:48:52 -0600
Message-ID: <460161FC.4000607@roguewave.com>
Date: Wed, 21 Mar 2007 10:49:00 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: [VOTE] Re: regression test suite naming convention
References: <7BDB2168BEAEF14C98F1901FD2DE643859446C@epmsa009.minsk.epam.com>
In-Reply-To: <7BDB2168BEAEF14C98F1901FD2DE643859446C@epmsa009.minsk.epam.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Mar 2007 16:48:52.0181 (UTC)
 FILETIME=[CE501050:01C76BD8]
X-Virus-Checked: Checked by ClamAV on apache.org

Farid Zaripov wrote:
>> -----Original Message-----
>> From: Andrew Black [mailto:ablack@roguewave.com] 
>> Sent: Wednesday, March 21, 2007 5:57 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: [VOTE] Re: regression test suite naming convention
>>
>> If we constrain ourselves to the proposed options, my vote is 
>> for Option 2.  The reason for this vote is because it allows 
>> us to more easily determine what regression tests need to be 
>> run for a particular change.
>>
>> If we don't constrain ourselves to the proposed options, I 
>> wish to put forward an additional option.
>>
>> Option 3:
>>     Put all regression tests in tests/regress/, using the following
>>     naming convention:
>>     tests/regress/<section-number>.stdcxx-<issue-number>.cpp
>>
>> This option would allow us to quickly locate all regression 
>> tests, and identify which section each regression test 
>> applies to without consulting Jira.
> 
>   I'm voting for option 3. Because that tests are not depends on the
> rwtest library, I think they would be in separate directory
> (tests/regress/).

Good point! Yes, the regression tests do not need the rwtest
driver and probably shouldn't even link with it. Storing all
the tests in the same directory would make implementing this
change in the makefiles easier.

This also raises the question of how the regression tests
should be run. The exec utility expects tests to produce
output in a certain format. Tests that don't are normally
reported with the FORMAT status. The utility (and probably
also the makefile infrastructure) would need to change to
accommodate tests with this type of output.

Martin