public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Zack Weinberg <zackw@panix.com>
Cc: <libc-alpha@sourceware.org>
Subject: Re: Add script to build many glibc configurations
Date: Thu, 17 Nov 2016 17:51:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.20.1611171747300.21214@digraph.polyomino.org.uk> (raw)
In-Reply-To: <dcc3fd8e-0865-af11-a998-10fbea75009c@panix.com>

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

  parent reply	other threads:[~2016-11-17 17:51 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-09 16:27 Joseph Myers
2016-11-10 14:27 ` Joseph Myers
2016-11-10 16:44   ` Joseph Myers
2016-11-23 17:36   ` Chris Metcalf
2016-11-10 17:09 ` Steve Ellcey
2016-11-10 17:22   ` Joseph Myers
2016-11-10 17:39     ` Steve Ellcey
2016-11-11 15:20 ` Joseph Myers
2016-11-11 19:37   ` Carlos O'Donell
2016-11-14 15:06   ` Mike Frysinger
2016-11-14 15:23     ` Joseph Myers
2016-11-14 19:27       ` Mike Frysinger
2016-11-14 23:28         ` Joseph Myers
2016-11-14 23:57     ` Joseph Myers
2016-11-17 16:52 ` Zack Weinberg
2016-11-17 17:26   ` Zack Weinberg
2016-11-17 17:47     ` Joseph Myers
2016-11-17 17:54     ` Andreas Schwab
2016-11-17 17:51   ` Joseph Myers [this message]
2016-11-18 16:28     ` Zack Weinberg
2016-11-18 18:27       ` Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1611171747300.21214@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=zackw@panix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).