public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] extras: New test/build infrastructure
Date: Fri, 25 Nov 2016 18:24:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.20.1611251820270.12591@digraph.polyomino.org.uk> (raw)
In-Reply-To: <08a9e327-a42c-a1d4-dadc-4dddd15e3183@redhat.com>

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 <extras/test-skeleton.c>
> 
> ?  Or do you want me to replace test-skeleton.c with a version which already
> includes <extras/test-skeleton.c>?  (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.)

(Changing all tests later to use a different name from 
"../test-skeleton.c" is fine, but I think such a global change to all 
tests' sources is best kept out of the initial patch.)

-- 
Joseph S. Myers
joseph@codesourcery.com

  reply	other threads:[~2016-11-25 18:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-25 15:59 Florian Weimer
2016-11-25 16:14 ` Zack Weinberg
2016-11-25 17:11   ` Andreas Schwab
2016-11-25 17:46     ` Florian Weimer
2016-11-25 17:45   ` Florian Weimer
2016-11-25 18:44     ` Zack Weinberg
2016-11-25 18:49       ` Florian Weimer
2016-11-25 16:16 ` Florian Weimer
2016-11-25 17:29 ` Joseph Myers
2016-11-25 17:48   ` Florian Weimer
2016-11-25 18:24     ` Joseph Myers [this message]
2016-11-25 19:26       ` Florian Weimer

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.1611251820270.12591@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /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).