Return-Path: Delivered-To: apmail-httpd-test-dev-archive@www.apache.org Received: (qmail 62589 invoked from network); 15 Sep 2004 23:49:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 15 Sep 2004 23:49:36 -0000 Received: (qmail 16312 invoked by uid 500); 15 Sep 2004 23:49:16 -0000 Delivered-To: apmail-httpd-test-dev-archive@httpd.apache.org Received: (qmail 16246 invoked by uid 500); 15 Sep 2004 23:49:15 -0000 Mailing-List: contact test-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: test-dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list test-dev@httpd.apache.org Received: (qmail 16210 invoked by uid 99); 15 Sep 2004 23:49:15 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from [66.77.29.165] (HELO secure.exclamationlabs.net) (66.77.29.165) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 15 Sep 2004 16:49:13 -0700 Received: from modperlcookbook.org (pcp04036320pcs.walngs01.pa.comcast.net [68.81.212.103]) (authenticated (0 bits)) by secure.exclamationlabs.net (8.11.6/8.11.6) with ESMTP id i8FNnCU16015 for ; Wed, 15 Sep 2004 18:49:12 -0500 Message-ID: <4148D4EA.9050800@modperlcookbook.org> Date: Wed, 15 Sep 2004 19:48:58 -0400 From: Geoffrey Young User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: test-dev@httpd.apache.org Subject: Re: run_tests and test_clean References: <41488E71.2010208@modperlcookbook.org> <4148CE2C.1040609@stason.org> In-Reply-To: <4148CE2C.1040609@stason.org> X-Enigmail-Version: 0.83.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N > Are you sure that there will be no side effects? I'm pretty sure. it's not like test_clean won't be called under normal 'make test' circumstances, it's just that now there would be a way around it if the user thinks it is beneficial. > If yes, then +1 ok, cool. if things blow up then I'll revert it, but I'm not seeing any problems on my end. > > Why not just run t/TEST directly instead of using make? I never use make > when developing tests. So it was never an issue for me. t/TEST works fine for smallish things, but make is nice for automatically computing and including library directories spread out all over the place. --Geoff