From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95081 invoked by alias); 17 Nov 2016 17:51:58 -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 95067 invoked by uid 89); 17 Nov 2016 17:51:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=wish X-HELO: relay1.mentorg.com Date: Thu, 17 Nov 2016 17:51:00 -0000 From: Joseph Myers To: Zack Weinberg CC: Subject: Re: Add script to build many glibc configurations In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2016-11/txt/msg00636.txt.bz2 On Thu, 17 Nov 2016, Zack Weinberg wrote: > On 11/09/2016 11:27 AM, Joseph Myers wrote: > > This patch adds a Python (3.5 or later) script to build many different > > configurations of glibc, including building the required cross > > compilers first. It's not intended to change any patch testing > > requirements, although some people may wish to use it for high-risk > > patches such as adding warning options ... > > Since this does its own glibc checkout, it's not clear to me how one > should use it to test a patch(set). I presume that whatever one does, > it only affects the "glibcs" step, but what actually do you do? Do you > manually update /some/where/src/glibc to contain the code you want > tested and then run "glibcs", or do you somehow tell > build-many-glibcs.py the name of a branch you want tested, or what? You patch the script's glibc checkout (or switch it to a different branch, or whatever) at some point after the checkout step and before running the "glibcs" build. (The model is that if you're often running tests for many configurations, you do the host-libraries and compilers steps once, with some stable GCC version, and then can keep using the previously built compilers when running the "glibcs" step with new and possibly patched glibc - so saving time compared to rebuilding the compilers from scratch every time.) (The checkout step will not notice if you've manually patched or changed the branch of a checkout, and will fail if git pull fails, e.g. if it tries to update a file where you have local changes.) -- Joseph S. Myers joseph@codesourcery.com