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 >
