From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110481 invoked by alias); 25 Nov 2016 19:26:53 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 110450 invoked by uid 89); 25 Nov 2016 19:26:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Subject: Re: [PATCH] extras: New test/build infrastructure To: Joseph Myers References: <9426ee75-3e45-6cde-b659-567398007a32@redhat.com> <08a9e327-a42c-a1d4-dadc-4dddd15e3183@redhat.com> Cc: GNU C Library From: Florian Weimer Message-ID: Date: Fri, 25 Nov 2016 19:26:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2016-11/txt/msg00942.txt.bz2 On 11/25/2016 07:24 PM, Joseph Myers wrote: > On Fri, 25 Nov 2016, Florian Weimer wrote: > >>> I think there would be clear advantages to setting things up so that all >>> existing tests can use the new code with no changes at all. That is, make >>> test-skeleton.c look more or less like your extras/test-skeleton.c, with >>> additional code to handle any missing pieces (e.g. >> >> Can you clarify what the goal is? If the >> >> #include "../test-skeleton.c" >> >> is at the end, it shall be possible to replace it with >> >> #include >> >> ? Or do you want me to replace test-skeleton.c with a version which already >> includes ? (All names subject to revision.) > > I would like test-skeleton.c to either include extras/test-skeleton.c, or > have essentially its contents in your patch, so that existing tests don't > need changing at all to use the new facilities. (This implies making your > intrastructure support all the facilities test-skeleton.c does.) This > should work regardless of where in the test sources test-skeleton.c is > included. > > (If there are a few tests for which full compatibility is hard, the patch > might fix those at the same time as making the changes to test-skeleton.c. > But unchanged tests should use the new facilities and the number of tests > that need changing to make that so should be as few as possible.) Okay, what you suggest is reasonable. I'll prepare a patch along these lines. I'll also change the subdirectory name to “support”, as Zack suggested. Thanks, Florian