public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: "Maciej W. Rozycki" <macro@wdc.com>, libffi-discuss@sourceware.org
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH libffi 1/4] Use a template to pass $CC and $CXX to DejaGNU
Date: Mon, 06 Apr 2020 11:58:07 -0600	[thread overview]
Message-ID: <0ecc64ec31aa62915bbae1b88bdb42934bbdf371.camel@redhat.com> (raw)
In-Reply-To: <alpine.LFD.2.21.2004031343310.461@redsun52.ssa.fujisawa.hgst.com>

On Fri, 2020-04-03 at 23:55 +0100, Maciej W. Rozycki via Gcc-patches wrote:
> Use an Autoconf template rather an inline piece of scriptery to set 
> DejaGNU's $CC_FOR_TARGET and $CXX_FOR_TARGET variables from $CC and $CXX 
> respectively, making it easier to maintain and making it take advantage 
> of Automake's dependency and rule generation.  Relocate the generated 
> `local.exp' file to within testsuite/ so as to make its regeneration 
> rule to actually work, i.e. (in testsuite/Makefile.in):
> 
> EXTRA_DEJAGNU_SITE_CONFIG = local.exp
> site.exp: Makefile $(EXTRA_DEJAGNU_SITE_CONFIG)
> 	[...]
> local.exp: $(top_builddir)/config.status $(srcdir)/local.exp.in
> 	cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
> 
> It wouldn't work if the regeneration rule was placed in the top-level 
> Makefile.in, which is what Automake would faithfully do if `local.exp' 
> stayed in the top level directory.
> ---
> Hi,
> 
>  I think having individual AC_CONFIG_FILES macro invocations for each 
> output file or group of files would make this change (and code itself) 
> more readable, however it hasn't been done before and I decided not to 
> change the style on this occasion.  It may make sense as a follow-up 
> clean-up.
> 
>   Maciej
> ---
>  Makefile.am            |    3 ---
>  configure.ac           |    7 +------
>  testsuite/Makefile.am  |    2 +-
>  testsuite/local.exp.in |    2 ++
>  4 files changed, 4 insertions(+), 10 deletions(-)
So from the cover letter I got the impression this series was supposed to be
pulling down some bits from upstream libffi into gcc's copy.  But AFAICT that's
not the case.

I don't see anything inherently wrong here.  It was just a bit confusing.  It's
actually follow-on patches where you're cherry picking from the upstream libffi
repository.

OK for the trunk.
jeff
> 


  reply	other threads:[~2020-04-06 17:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03 22:55 [PATCH libffi 0/4] Robustify compiler and library path selection in the testsuite Maciej W. Rozycki
2020-04-03 22:55 ` [PATCH libffi 1/4] Use a template to pass $CC and $CXX to DejaGNU Maciej W. Rozycki
2020-04-06 17:58   ` Jeff Law [this message]
2020-04-03 22:55 ` [PATCH libffi 2/4] Use a documented way to pass $compiler_vendor " Maciej W. Rozycki
2020-04-06 18:00   ` Jeff Law
2020-04-03 22:56 ` [PATCH libffi 3/4] Make `libffi-init' use $CC_FOR_TARGET Maciej W. Rozycki
2020-04-06 18:03   ` Jeff Law
2020-04-03 22:56 ` [PATCH libffi 4/4] Correct indentation throughout `libffi-init' Maciej W. Rozycki
2020-04-06 18:01   ` Jeff Law
2020-04-14 13:59 ` [PING][PATCH libffi 0/4] Robustify compiler and library path selection in the testsuite Maciej W. Rozycki
2020-04-20 12:50 ` [PING^2][PATCH " Maciej W. Rozycki

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=0ecc64ec31aa62915bbae1b88bdb42934bbdf371.camel@redhat.com \
    --to=law@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libffi-discuss@sourceware.org \
    --cc=macro@wdc.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).